HomeMy WebLinkAboutExhibit7Safetypad Implementation
Statement of Work
DRAFT
Miami Fire Rescue
Contents
Project Overview and Responsibilities 3
Introduction 3
Project Background 3
Project Vendors 3
Constituent Responsibilities 4
Implementation Team 6
Technical Overview 7
Services Provided By OPEN, Inc 7
Description 8
Software Provided By OPEN 8
Assumptions 8
Project Detail 8
Project Timeline 9
Key Milestones, Deliverables, & Responsibilities 9
Project Planning 9
Ongoing Project Management 10
Technical Infrastructure 10
Design Phase 11
Build Phase 12
Test Phase 13
Deploy Phase I 14
Final Acceptance Period 15
Approvals 15
Appendices 21
Issues Resolution Process 21
Change Request Process 21
2
Project Overview and Responsibilities
Introduction
The purpose of this document is to document the initial project definition so that all
stakeholders have a mutual understanding of the scope before significant resources are
committed and expenses incurred. For the purpose of the project, any items not included
within this Statement of Work (SOW), are considered outside of the scope of this project.
Should any additional needs be discovered or defined during the execution of the project,
a Change Request must be submitted, which subsequently may affect the scope, schedule,
and/or cost of the project.
Project Background
The City of Miami Fire Rescue (MFR) conducted a detailed selection process to find a
partner to assist them with their implementation of a field data collection system as well
as improving their EMS billing. OPEN, Inc submitted its proposal to MFR (dated
November 21, 2007) providing a comprehensive and integrated solution to MFR's EMS
Field Reporting requirements, and was ultimately selected.
MFR's vision focuses on electronic patient care reporting in a technical environment built
under standard EMS guidelines. The solution offers an enterprise -wide platform capable
of supporting all MFR's physical and mobile locations while providing:
• Rapid availability of patient care data for quality improvement, system analysis,
and risk management activities
• Improved field data capture
• Consistent and efficient field documentation processes
• Enhanced reporting
• A foundation for future field technology initiatives
The current strategy to achieve the vision is to:
• Implement the Safetypad field data solution to capture patient care report (PCR)
data electronically
• Submit PCR data electronically to all necessary locations (i.e hospitals, billing)
• Submit PCR data reports electronically to EMSTARS/NEMSIS agencies.
Project Vendors
The project utilizes the strengths of several key industry players to provide the overall
solution. The key industry players are:
• OPEN, Inc, a national premier industry provider of EMS EPCR solutions ;
3
• Panasonic USA, Inc., a leading designer and manufacturer of rugged tablet
computers.
CONSTITUENT RESPONSIBILITIES
MFR will be the project owner and will provide approval on all milestones required in
providing the total solution. MFR will be directly responsible for:
1. Providing day-to-day project management.
2. Providing access to the necessary information, reports, and personnel to enable the
completion of this project in the timeframe estimated.
3. Designate functional, technical, support, and project management resources to be part
of the project team prior to the start of the project, as indicated in the implementation
team section below.
4. Providing access to work space, phones, interne and network access, copiers, and
faxes, as reasonably necessary while contractors are working on the premises, if
needed.
5. Providing timely acceptance of deliverables. If MFR does not provide sign-off(s)
acceptance or written notice documenting any objections within 5 business days of
submission of a deliverable, then the deliverable will be deemed accepted and team
will move ahead with the project.
6. Completing workplan task responsibilities by the dates indicated in the workplan.
7. Facilitating prompt issue resolution.
8. Leading the design of processes, workflows, configuration, security, and reports.
9. Collecting and entering all required configuration data into the system.
10. Assisting in the identification and documentation of technical requirements, including
the technical architecture.
11. Providing the server hardware, station workstations, operating system, and backup
solution for the application that meet OPEN's minimum requirements.
12. Providing and leading the installation of all server and network requirements.
13. Maintaining and supporting all server and network hardware and software
requirements.
14. Maintaining the server environments, including development, test/train, and
production.
15. Install and test all non-Safetypad software prior to migration to production.
16. Coordinating and completing vehicle hardware installation with MFR's Radio Shop.
17. Procurement, installation, and maintenance and support of any hardware or software
not listed within this SOW.
18. Identify in-house training staff and developing the deployment schedule.
19. Providing adequate training facilities and equipment, including a conference room
with adequate space and seating/conference table space, white board, overhead
projector, and computer projector.
20. Conducting training for all users.
21. Staging the proper installation of all Safetypad software in both the field units and the
server after successful completion of user acceptance testing, ensuring proper end -to -
end operation.
22. Conducting training for all users for any non-Safetypad requirements.
4
23. Establishment of methods and tools for OPEN support to remotely connect to the
server.
24. Designating a Safetypad System Administrator as the primary contact for the OPEN
Technical Support after the system has gone live.
25. Providing the necessary resources — CAD software (API or custom software), CAD
consulting services, and any additional hardware not listed within this SOW that is
required to develop items not identified.
26. Virus software installation and distribution of updates to field units.
27. Operating System upgrades and distribution of updates to field units.
28. Provide field unit operating system and network specific access security measures -
system access security will be maintained through Windows XP mechanisms. This
provides security on a domain or local system level and provides the ability to encrypt
hard drive folders.
OPEN, INC will be the prime contractor and coordinate all activities required in
providing the total solution. OPEN, Inc will be directly responsible for:
1. Providing program management, methodology and quality assurance throughout the
duration of the project.
2. Designate project resources prior to the start of the project as indicated in the
implementation team section below.
3. Completing workplan task responsibilities by the dates indicated in the workplan.
4. Coordinating all vendor activities.
5. Leading the issues resolution process.
6. Purchasing the necessary hardware and software as specified within this SOW.
7. Preparing and maintaining detailed implementation plans.
8. Conducting weekly status report meetings onsite or by phone.
9. Creating and distributing weekly status reports.
10. Providing specific functional/technical knowledge in systems, including examples
and recommendations from previous experiences.
11. Providing a secure file transmission mechanism for the transmission of databases or
other information as necessary
OPEN will provide the software and expertise required for implementing the field data
capture system. OPEN will be responsible for:
1. Providing day-to-day project management.
2. Designate project resources prior to the start of the project as indicated in the
implementation team section below.
3. Completing workplan task responsibilities by the dates indicated in the workplan.
4. Facilitating prompt issue resolution.
5. Providing specific functional/technical knowledge in field data system related
processes and systems, including examples and recommendations from previous
experiences.
6. Providing the field data application solution that matches the requirements outlined in
the RFP or as outlined by attachment to this SOW, including the minimum
specifications in Section V and specifically items # 28.8, 28.15, 30, 50, 285,
excluding the other requirements identified as exceptions in the RFP response.
5
7. Leading the design and development of integration including any interfaces required
as listed in the RFP or as outlined by attachment in this SOW.
8. Leading the testing effort, including the development and execution of the test plan
and scripts, as well as test issue resolution.
9. Developing training materials in accordance with the requirements in the RFP.
10. Providing on site Safetypad training for system administrators, administrative users,
trainers, end users, as laid out in the RFP.
11. Review and certificate MFR trainers.
12. Determining all software, hardware and networking requirements, including adequate
backup facilities, with the active assistance of MFR.
13. Documenting the technical architecture.
14. Documenting technical process, including maintenance and support.
15. Staging the proper installation of all Safetypad software in both the field units and the
server, ensuring proper end -to -end operation through successful completion of user
acceptance testing.
16. Providing ongoing maintenance and software support via OPEN's maintenance and
support program.
Statement of Work tasks may not always start and complete in a sequential manner, but
may overlap. The completion and acceptance of any task is not contingent upon the
completion of a previously defined task unless specifically identified.
IMPLEMENTATION TEAM
The success of the overall project will be dependent upon the ability of the resources to
work together as a team with a common purpose and vision. In support of developing an
effective team, the following resources are being committed for this effort:
MFR will provide the following team members:
Project Sponsors (Chief Joyce) — Project sponsors will facilitate decision-making/issues
resolution and promote consistency, as well as support the implementation of the solution
from a strategic perspective in conjunction with MFR's goals. Project commitment is as
needed.
Project Manager (Kevin Burns, PMP) —Will lead the day to day project management,
participate in status meetings, provide access to MFR personnel, approve deliverables,
help speed the decision -making and issues resolution processes, facilitate both internal
and external communication, and support the design of the system from a strategic
perspective. Project commitment is expected to be 40%.
Functional Lead/Manager (Lt. Tom Pupo) — This individual will participate in status
meetings, provide access to functional MFR personnel for the purposes of solution
design, testing and training, review and help generate deliverables, and participate in the
decision -making and issues resolution processes.
Functional Resources (Resources will be identified as needs arise) — These resources will
be responsible for providing MFR legacy business process knowledge and configuration
data. They will assist in the design of configuration, reporting, testing, and training as
6
well as provide preliminary configuration feedback prior to utilization. Project
commitment is as needed.
Initial users — These resources will be identified during the design phase when the
training plan is created. Approximately 6 users are expected to be part of this group,
including paramedics, rescue captains, and fire response. They will have an active role in
providing solution feedback during the build and test phases of project. Members of this
group will also be the first to go live on the solution. Project commitment is as needed..
Technical Lead/Manager (Mark Stielow) — This individual will participate in status
meetings, provide access to technical resources, and ensure the stability of the hardware
and software solutions.
Technical Resources (Resources will be identified as needs arise) — These resources will
assist in the identification of hardware and software requirements, install hardware and
software, assist in the design and development of the technical architecture, interfaces,
reports, customizations, and security, as well as provide resolution of test issues and
production support.
OPEN, Inc will provide the following team members:
Quality Assurance (Mark Dodd) — Mark will promote consistency in project deliverables,
as well as support the implementation of the solution from a strategic perspective in
conjunction with MFR's goals. Project commitment is as needed.
Project Manager (Scott Streicher) — Scott will be responsible for planning, coordinating,
and providing quality assurance for the Safetypad software implementation. This
includes assisting the team in defining the project standards and methodologies, seeing
that the solution facilitates future design efforts, coordinating project vendors, and
facilitating communication. Project commitment is expected to be As needed to meet the
project requirements.
Subject Matter Experts ( ) — If needed, these resources will provide expertise
on matters that need specific attention through the installation process. Project
commitment is as needed.
Technical Overview
The services, hardware, and software items listed below will be procured by OPEN, Inc
for the purpose of the project. Should newer, different models, or specifications be
desired, hours for those items will be determined at the time of request.
SERVICES PROVIDED BY OPEN, INC
OPEN, Inc and OPEN will fulfill all of the service responsibilities detailed in this SOW
for the costs depicted in the total cost column. Should a project change order be needed,
or additional services required, costs will apply.
7
DESCRIPTION
OPEN, Inc Professional Services: Time required for project
management, implementation and deployment of the solution.
OPEN Project Management: Time required for project
management of the solution.
OPEN IT Implementation: On -site time required for the IT
infrastructure implementation of the solution.
OPEN Deployment: Time required for the deployment and
training of the solution.
OPEN Inc. Development: Time required for development of
custom solutions (reports, fields, interfaces, etc.). 300 hours of
report development included. Please see the software section
below for a detailed list of included interfaces.
OPEN, Inc Travel & Expense — On -site travel and expense
items including plane, rental car, meals, taxis, etc.
OPEN Annual Maintenance & Software Support: As defined
in the contract..
SOFTWARE PROVIDED BY OPEN
See REV 3 of OPEN INC - RFP 55025 RESPONSE SECTION VIII - PRICING - Apr 9
2008 FINAL.xls
Assumptions
1. Items below are not included within the current scope of this project, but can be
provided via the change request process.
a. Hospital desktop docking stations — Provides tablet charging and hard wire
connection to a printer while in the hospital.
b. Magnetic card reader technology and integration to Safetypad — Allows field
users to populate patient information to the Safetypad application with the
swipe of a driver's license, insurance card, etc.
c. Annual spares program — Allows for an additional quantity of items each year
in the event of breakage.
d. Spare batteries
e. Hospital printer toner and paper.
f. Non-Safetypad software — Such as MS Office.
g. Any additional software, hardware or cables not listed within this SOW that
are required for the Tiburon MDT/CAD interface.
h. Any consulting fees, software license fees, or development costs charged by
(CAD) as required to implement the CAD interface.
2. The current OPEN NEMSIS extract will meet the state/county EMSTARS
specifications.
PROJECT DETAIL
8
PROJECT TINIELtNE
Completion of the Safetypad field data system implementation may take up to 52 weeks,
but the intent is to complete the project in the shortest timeframe possible. High level
tasks, deliverables, timelines, and stakeholder responsibilities of each phase are discussed
below.
KEY MILESTONES, DELIVERABLES, & RESPONSIBILITIES
The responsibility column identifies the stakeholder group responsible for the deliverable.
TASK I - PROJECT PLANNING
Detailed project planning will commence upon contract award. Total duration is
expected to be 4 weeks. During this phase tasks, timelines, and roles and responsibilities
will be formalized, and the project will formally be kicked off. Milestones and
deliverables of this phase are:
I£ TASKS & MILESTONES
DEL RABLES
RESPONSIBILITY
Solidify Project Scope — A project plan detailing
resource roles and responsibilities, hardware and
software requirements, etc. will be discussed in a
workshop format, formally documented,
distributed, approved and attached to this SOW..
Project Plan
Document
OPEN
Form Project Team — Team members will be
identified and appropriately scheduled.
Project Team
Organization Chart
OPEN
Create Detailed Project Workplan — All project
tasks will be identified, assigned, and scheduled
for an estimated duration.
Microsoft Project
Plan
OPEN
Establish Project Policies, Procedures, and Tools —
A steering committee will be formed with
scheduled meeting times and various document
templates and any necessary utilities will be
established and distributed.
Issues Log,
Status Reports,
Team Contact List,
Doc Sharing Tools,
Etc...
OPEN
Orient the Project Team — Core project team
members, as well as project sponsors will
participate in a kickoff meeting where project
timelines, tools, and responsibilities will be
communicated.
Kickoff
Presentation
OPEN
Completion Criteria:
This task is considered complete when:
• Project Kickoff Meeting has been held discussing roles/responsibilities.
• Detailed Project Workplan & Project Team Organization Chart is completed and
distributed.
• Steering committee is identified and document templates are distributed..
Task completion will be confirmed by the Customer's signature on the task completion
letter presented by Open.
9
TASK 2 - ONGOING PROJECT MANAGEMENT
The tasks associated with ongoing project management begin at the completion of the
project planning phase and continue through the completion of deployment. The
discussion and approval of the Technical Submittal changes will be attached. Total
duration is expected not to exceed 52 weeks. These tasks focus on ensuring that the
project stays on track and stakeholder expectations are exceeded. Milestones and
deliverables of this phase are:
Y TASKS & MILESTONES
DEL ES
IIESPONSIBILT
Monitor the Project - Conduct meetings to assess
and report the status, facilitate issues resolution,
execute the change order process, and approve
and update changes to the project workplan.
Transition the Project — At the end of this,
deployment, transition all open responsibilities to
MFR, provide final documentation set, conduct a
project close meeting, etc.
Completion Criteria:
Status Reports
Updated Project
Workplan
Project Change
Orders
Updated Issues
Logs
Final Project
Documentation
Project Close
Meeting
This task is considered complete when:
• Project Closeout Meeting is held.
• Final Project Documentation set is provided.
• All issues are resolved and system is fully operational.
OPEN
OPEN
Task completion will be confirmed by the Customer's signature on the task completion
letter presented by Open.
TASK 3 - TECHNICAL INFRASTRUCTURE
The tasks associated with receipt of, installation, and maintenance of the technical
infrastructure begin at the completion of project planning and continue until the start of
testing phase for hardware and software required for the project. Total duration for the
alpha group requirements is expected to be 4 weeks. Procurement and installation of
hardware and software will follow the deployment plan timeline. Milestones and
deliverables of this are:
Y
TASKS &
LEST?IYE
Define Technical Architecture — Identify all
technology components of the end state solution
and how they will integrate with one another.
Review Hardware Requirements — Based on the
technical architecture, insure a list of hardware
requirements for workstations, Panasonic
specific equipment, servers, vehicles, and
hospitals, including quantities and models for
DELIVE!
Technical
Architecture
Diagram
Hardware List
SPONSIBILI
OPEN/MFR
OPEN/MFR
10
each.
Review Software License Requirements —
Based on the technical architecture, insure a list
of software requirements, including quantities
of each is accurate.
Software List
OPEN
Receive Infrastructure Components — Place
orders for and receive all hardware and
software.
Hardware and
Software Orders
OPEN/MFR
Design Technical Processes — Define support,
maintenance, backup/recovery, environment
migration, etc. processes.
Technical Processes
Documentation
MFR
Conduct System Setup, Install & Configuration
Training — Train system administrators on the
technical aspects of the solution.
System Admin
Training
Documentation
OPEN
Install Server — Install the server hardware, load
applicable software, and create environments.
Server and Software
Installation
Documentation
MFR
Install, Configure, and Test Hardware &
Software — Install tablets, vehicles, hospitals,
and workstations that will be utilized by the
feedback group.
Installed Hardware
& Software
Installation Tracking
Documentation
MFR
Install, Configure, and Test Production
Hardware & Software — Install remaining
tablets, vehicles, hospitals, and workstations.
Installed Hardware
& Software
Installation Tracking
Documentation
MFR
Completion Criteria:
This task is considered complete when:
• Technical Architecture Diagram is completed.
• Hardware & Software requirements lists are completed and ordered.
• Servers are installed & System Setup/Backup are configured.
• System Administrator Training is completed.
• All hardware & software are installed, configured and tested.
Task completion will be confirmed by the Customer's signature on the task completion
letter presented by Open.
TASK 4 -DESIGN PHASE
The design phase will begin at the completion of project planning. Total duration is
expected to be 8 weeks. Milestones and deliverables for this phase are:
`.TASKS iVIILESTO
DEL
RESPONSIBI
Design Configuration — Design, document, and
validate protocols, open and close call rules,
and lists of values.
Configuration
Documentation
MFR
Design Business Processes — Design, document,
and validate the shift change, quality assurance,
Process
Documentation
MFR
11
etc. processes.
Design Training Plan — Formalize the training
and deployment plan including the
identification of trainers, delivery/rollout
strategy, schedule, etc.
Training Plan
MFR
Design Test Plan — Formalize the test plan
including the identification of testers, test issue
documentation and resolution processes, etc.
Test Plan
OPEN
Design Reports — Review existing reports and
document design for additional requirements.
Report Design
Document
MFR
Design Integration — Design, configure, test
and document CAD (through vehicle's MDT),
OPEN, Inc.
Integration Design
Document
OPEN
Receive Solution Design Approval —
Consolidate all design documents and receive
formal sign -off on single design document
(attachment to the SOW) .
Business
Requirements
Document (BRD)
OPEN
Completion Criteria:
This task is considered complete when:
• Configuration (protocol, open/close rules, etc.) design is completed.
• Business process design is completed.
• Training Plan and schedule is completed.
• System test plan is completed.
• Report design document is completed.
• CAD integration is completed and mutually agreed performance test is successful.
• Consolidation of all documents into BRD is completed.
Task completion will be confirmed by the Customer's signature on the task completion
letter presented by Open.
TASK 5 - BUILD PHASE
The build phase will begin at the completion of design phase with the formal approval of
the solution business requirements document (BRD). Total duration is expected to be 8
weeks. Milestones and deliverables for this phase are:
D'
RABL
SPONSIBILT
Build initial Application — Configure protocols,
open and close call rules, and list of values,
including:
• Personnel information
• Apparatus information
• Non -incident department codes
• Incident related department codes
• NFIRS reporting
• EMSTARS reporting
• Provide system security to assist
Initial
Configuration
MFR/OPEN
12
customer in being HIPAA compliant.
Build Training Products & Data — Build all
training products/materials (print ready CD-
ROM) as specified in the RFP to include
administration training such as:
• Hardware & Network configuration
• Software installation
• Client installation
• Updates
• Trouble shooting & technical support
• Backup & recovery procedures
• Code table maintenance
Training Materials
OPEN/MFR
Conduct Training — Train a select group of field
users from multiple stations. These users will
utilize the solution in the field in parallel with
the existing paper process and provide feedback
to core project team.
Initial Group
Trained
OPEN
Build Production Application — Modify
configuration based on initial group feedback.
Build reports as agreed, all integrations and test
scripts. Any deviation from the SOW or the RFP
agreed upon response will require a change
order..
Final Configuration
Final Test Scripts
OPEN, Inc
OPEN
Completion Criteria:
This task is considered complete when:
• Initial application is built.
• Training is completed for Miami test users.
• Miami test users complete testing in field.
• Modify initial application using feedback from test users.
Task completion will be confirmed by the Customer's signature on the task completion
letter presented by Open.
TASK 6 - TEST PHASE
The test phase will begin at the completion of build phase. Total duration is expected to
be 8 weeks. Milestones and deliverables for this phase are:
Y'TASKS'
MILESTO!
TB!
Sr:
SPONSIBILITY .'
Conduct Beta Test — Receive and modify the
production application based on field user
feedback.
Updated Solution
MFR
Establish Test Environment — Create test server
environment.
Test Environment
MFR
13
Open will demonstrate software functionality in
Minimum
Open
accordance to a mutually agreed uponMinimum
specifications
specifications in section V of RFP.
functionality test
Execute User Acceptance and Performance Test
Test Issues Log
MFR
- execute test scripts, stress test the system by
Application &
simulating capacity change over, record actual
Performance Test
results vs. expected, and log issues. Issues are
reviewed, resolved, and retested until users are
satisfied.
Sign -Off
Completion Criteria:
This task is considered complete when:
• Beta test is complete.
• Test server is created for system test.
• Functionality test of minimum specifications is completed.
• Performance test and user acceptance is completed.
• Final Production configuration and test scripts are completed.
Task completion will be confirmed by the Customer's signature on the task completion
letter presented by Open.
TASK 7 - DEPLOY PHASE I
Deployment will begin at the completion of test phase. Total duration is expected to be 4
weeks. Deployment will include the initial users, administrative users, and training of
MFR trainers. All training during this phase will be conducted by OPEN. Milestones
and deliverables for this phase are:
TASKS & ESTONES
DEI
SPONSIBILITY
Establish Production Environment — Migrate the
system from the test to production environment.
Deploy Trainers, initial Group, and Admin
Users — Train the trainers and administrative
users. Communicate any final training points to
the initial group and go live. Provide post "Go
Live" support.
Completion Criteria:
Production
Environment
Users Trained
Users Live
This task is considered complete when:
• Migration from test to production is complete.
• All user training is complete.
• Go Live is initiated.
MFR
OPEN
Task completion will be confirmed by the Customer's signature on the task completion
letter presented by Open.
14
TASK 8 - FINAL. ACCEPTANCE PERIOD
The final acceptance period will begin as soon as all deployment users are live. Total
duration is expected to be 90 Days. Milestones and deliverables for this phase are:
Y TASKS & MILESTONES
Dr' IVERABT S
RESPONSIBIL:
TV
Conduct 90 day reliability test.
Final Acceptance Period — Confirm that
hardware and software solutions are meeting
expectations and sign the project acceptance
document.
Reliability Test
Project Acceptance
Document
OPEN
OPEN
Completion Criteria:
This task is considered complete when:
• 90 Day reliability test is completed.
• Software is performing all the required functions as per the RFP consistently with
no bugs.
• All integration of systems are operational.
• Project acceptance document is signed off.
Task completion will be confirmed by the Customer's signature on the Project acceptance
document letter presented by Open.
Acceptance
Unit testing is conducted throughout each phase of the project. Acceptance Test Plan's
(ATP) will be created by Open and MFR that satisfy the deliverables of the SOW for
each phase and in accordance with the project plan/schedule. Acceptance of a particular
phase will be considered approved upon achieving a signature from both Open and MFR
approving that phase.
CONFIGURATION TESTING
Configuration testing is conducted by OPEN, Inc staff and is based upon the ATP for
Configuration.. The ATP will include test cases drafted by OPEN, Inc QA department
and executed to validate that the configuration data, Reference, Clinical and Server flow.
Test cases will clearly identify the results of the configuration activity performed and will
allow the client the opportunity and confirm that the configuration work submitted is
consistent with the configuration work performed. The Client then has a fixed period of
time, as determined and mutually agreed upon within the project plan, to further verify
that the configuration work has been properly executed. Once validated, changes to
configuration require the execution of a change order.
15
SYSTEM TESTING
System testing is conducted by OPEN staff and is based upon the written RFP 55025
RESPONSE SECTION V technical specifications submitted by City of Miami and the
ATP created by Open and MFR. The ATP will include test cases that are drafted by
OPEN, Inc QA department and executed to validate that the SafetyPAD system is
performing as expected. Test cases will clearly identify the results of the specifications
and will allow the client the opportunity to confirm that the mobile and backend portions
of the system are performing. Full testing is performed at the client site once the software
has been installed in accordance to the ATP.
Go LIVE ACCEPTANCE TESTING
Once the SafetyPAD® product has received configuration approval, the suite of products
are loaded on the client site for Go Live Acceptance testing. Testing will be conducted
by a control group of users identified by MFR who will verify that all aspects of the
system pass the ATP. Testing issues that are identified by the control group will be
reported and documented by Open Inc. and will be tracked to closure. Issues arising
during testing are reviewed with Project Managers and specific resolutions are identified.
Issues are flagged as:
• Priority 1 — must be corrected prior to mutually agreed go -live date.
• Priority 2 — should be corrected but work-around(s) can be identified.
• Priority 3 — not required for go -live but must be corrected during 90 day SRT.
A formal change process will be completed for all priority issues clearly identifying any
impacts they might have on project schedule.
OPEN, Inc deployment standards require testing prior to releasing final configured
software for go live conversion. If necessary, "go live" expected dates will be adjusted to
allow for the resolution of priority issues based on an agreed upon schedule.
During Go Live Acceptance testing, clients typically perform one or both of the
following: Parallel testing in a live environment; and/or test case data input. In
accordance with the ATP, test cases will be developed to verify end -to -end system testing
of data collection and go -live interface requirements.
If MFR chooses a parallel process this will be conducted over a two -week period utilizing
the control group. During this testing, electronic records will be collected in parallel with
the existing system. The purpose of the testing is to verify the data is moved through
each step accurately and reliably. The system testing will include data entry, transmission
from the tablet to the server, CAD to tablet, server to the tablet, assignment between all
groups on the server, printing, and finally ending with an export to billing if required for
go -live IAW the ATP.
During this period, the client will certify that all aspects of the system required for go live
are functioning. These include the following:
16
• Acknowledgement from City of Miami that all tablet and server hardware,
and all software licenses as specified by this charter and/or as evidenced by a
properly executed change order, have been received
• Acknowledgement from City of Miami that tablet and server software have
been configured in accordance with direction provided from City of Miami
• Acknowledgement from City of Miami that network infrastructure is
functioning as intended
• Acknowledgement from City of Miami that proper technical security, back-up
procedures have been identified and tested and are performing as intended
• Acknowledgement from City of Miami that proper operational procedures
have been identified, documented, and understood by all staff responsible for
their execution
• Acknowledgement from City of Miami that on -going vehicle installations are
proceeding in accordance with project plan and are sufficient to support post
live roll out processes
• Acknowledgement from City of Miami that end -to -end testing has been
performed and that the system is documenting, storing and retrieving data in
accordance with identified requirements
• Acknowledgement from City of Miami that medic and other staff have been
trained sufficiently to operate the system as defined.
SYSTEM RELIABILITY
• The system reliability period is the 90-day period immediately following the
initial go -live date, also identified in the contract as (25) field unit
collecting production data. During that period any critical system failure
issues with the SafetyPAD EMS System will be documented by City of
Miami and reviewed with OPEN, Inc. At the end of the period, provided
the SafetyPAD EMS System is functioning in accordance with the final
acceptance criteria described in RFP 55025 RESPONSE SECTION V, the
client shall accept the SafetyPAD EMS System and make the final
payment as described in section four (4) of the contract. In the event the
System does not function in accordance with the acceptance criteria
described in 55025 RESPONSE SECTION V as amended or the ATPThe
17
following criteria will be followed with regards to the 90 day time period in
which the malfunction is to be resolved:
• All Priority 1-2 Problems that are the direct and exclusive responsibility of
Open will stop the 90 day SRT until fixed.
• If a Priority 1 Problem occurs (that is the direct and exclusive
responsibility of Open) and is not resolved within 48 contiguous hours, the
90 day SRT will be reset to day one.
• If a Priority 2 Problem occurs (that is the direct and exclusive
responsibility of Open) and is not resolved within 120 contiguous hours,
the 90 day SRT will be reset to day one.
• If the Priority 1-2 Problems occur (that are the direct and exclusive
responsibility of Open) in the last 30 days of the of the System Reliability
Test (90 days) test period, the 90 day SRTwiIl stop until fixed and an
additional 30 days will be added to the 90 day SRT.
• Any Priority 3 Problems will stop the 90 day SRT until a work around is put
into place or defined, and then the SRT will resume. These are considered
lower priority and must be resolved within the 90 day SRT period.
POST LIVE ACCEPTANCE
Any requirements mutually determined to be not critical for the "go live" could be
completed after implementation and according to the project schedule/plan. Testing and
acceptance of these requirements will follow the same procedures as all previous testing
and ATPs. When ready to be implemented, these requirements will have a 90 day
reliability test for final acceptance and all rules of the 90 day reliability test will be
complied with.
The following identifies the process that will be followed to gain Final Acceptance. Any
requests or requirements to make a fundamental change to this process must be agreed
upon, through a formal Change Order Process, to ensure understanding and agreement by
both OPEN, Inc and the Customer.
FINAL ACCEPTANCE
Final system acceptance will be achieved at the conclusion of the 90 day reliability test
period. Signatures from Open and MFR will be obtained to memorialize that date. Final
contract acceptance will be achieved when all requirements and outstanding defieicences
identified during the 90 day reliability period where work arounds have been provided are
resolved, tested, and accepted per the same procedures and standards previously
described in the SOW. At a minimum the following will be demonstrated:
• Resolution of Priority 1 and 2 defects
• A working standard export program to State reporting, in accordance with the
requirements
18
• A working export function to the Customer's Billing application, in accordance with
the requirements
• A working standard interface program with the Customer's Records Management
Systems, in accordance with the requirements
Procedures will be established and published denoting the methods to report any
deficiencies discovered after the 90 day reliability period.
The day following the satisfactory conclusion of the 90 day reliability period with
appropriate signatures is when the one year warranty period begins and the account is
transitioned to the support network. Any subsequent requested changes to scope, changes
to configuration, and minor, non -critical issues that are not critical stop issues are subject
to normal scope change definition and cost estimation.
Approvals
Signature below signifies that all stakeholder groups have reviewed and approved the
scope of work outlined in this document, as well as the detailed task responsibilities in
the Microsoft Projects Plan.
Miami Fire Rescue
Name:
Signature:
Title:
Date:
OPEN, Inc
Name:
Signature:
Title:
19
Date:
OPEN Incorporated
Name:
Signature:
Title:
Date:
20
Appendices
ISSUES RESOLUTION PROCESS
During the course of implementation on any project of this level of complexity, it is
expected that a number of issues will arise. Having a formal issues resolution process
will ensure that issues are captured and resolved on a timely basis, so that the project
timeline is not impacted.
Upon issue identification via design sessions, status meetings, etc., the issue will be
captured in the implementation issues log by project management. During weekly status
meetings new issues will be discussed by project management and team leads. At this
time, issue resolution ownership will be assigned to a team member. Existing issues in an
open status will also be discussed at the weekly status meetings. In this case, the issue
resolution owner will lead the discussion.
On a bi-monthly basis, the project management team will prepare for the project sponsor
meeting. As part of the preparation for this meeting, all issues will be reviewed. In
particular, issues that have been outstanding for three weeks or more will receive
additional attention. The project management team will make every attempt to resolve
these issues as part of the project sponsor meeting preparation. Issues that are not
resolved as part of the project sponsor meeting preparation, and require a higher level of
management review will be presented to the project sponsors for resolution during the
monthly project sponsor meeting.
CHANGE REQUEST PROCESS
It may become necessary to amend this Statement of Work for reasons including, but not
limited to, the following:
• Discretionary changes to the project schedule
• Discretionary changes in the scope of the project
• Non -availability of products, resources or services
• Environmental or architectural impediments not previously identified
• Lack of access to client personnel or facilities necessary to complete project
In the event that it is necessary to change this Statement of Work, the process outlined
below will be followed:
A Change Request (CR) will be the vehicle for communicating change. The CR will
clearly state the reason for the change, how the requests deviates from the original scope,
as well as the affect on the project tasks, deliverables, timeline, and cost.
A CR may be initiated by either MFR, OPEN, Inc, or OPEN based on the situation. All
stakeholder groups will review the proposed change and approve it or reject it. If further
investigation on the part of OPEN, Inc or OPEN is required in order to determine the
scope of the change, any charges for that investigation will be outlined.
Upon signature of the CR by all parties, the scope of work and costs will be modified
appropriately, and the changes will be incorporated into the project. Work on the change
will not begin until all signatures have been received.
21