I.
INTRODUCTION
A. Charter Purpose
The purpose of this charter is to
document an understanding among OCFS, the CONNECTIONS Executive Steering
Committee and CONNECTIONS Management Committee who represent Local District and
Voluntary Agency administrators, managers, line, and technical staff regarding
the completion of the CONNECTIONS Project.
This charter will include a definition of project scope, assumptions,
development and implementation approach, project roles and a preliminary
project budget. This charter will serve as the foundation for the development
of detailed statements regarding the scope of the project, development work
plan and resource requirements.
B.
Project Background & Rationale
The New York State
Office of Children and Family Services (OCFS) is responsible for the
supervision and oversight of child welfare services that are provided through
58 Local Departments of Social Services (LDSS), including New York City’s
Administration for Children Services (ACS) and over 350 Voluntary Agencies. OCFS, Local Districts, and the Voluntary
Agencies form a network that provides for the safety and well-being of children
and families. OCFS is also responsible
for direct care services to youth in the Juvenile System.
In 1986, the U.S. Congress, concerned about the lack of information available on children in foster care and their families enacted legislation that requires the Federal government to institute a foster care and adoption data collection system. (AFCARS) Ultimately federal regulations were promulgated that required the states to provide such information in a consistent and reliable fashion. The Omnibus Budget Reconciliation Act of 1993 provided enhanced federal funding for states to build Statewide Automated Child Welfare Information Systems. (SACWIS) The objectives of these systems included assisting the states to submit AFCARS, and to promote the effective administration of services provided in Child Protective, Preventive, Foster Care and Adoption.
The New York State
SACWIS project is CONNECTIONS. The
CONNECTIONS Project is a statewide effort to provide OCFS, LDSS, and Voluntary
Agencies with an automated tool that would provide a uniform system to improve
the quality and consistency of their efforts on behalf of children and their
families. When complete, the project
will automate Child Welfare record keeping and service delivery through the
installation of hardware and software.
When fully implemented, the system will provide case management support
for direct caseworkers, decision-making support tools for managers, and
appropriate access to client information across the state. Through the
statewide network, CONNECTIONS will link child welfare caseworkers,
supervisors, and other management and administrative staff.
The initial
development of CONNECTIONS was undertaken in 1996. In response to stakeholder-identified issues
with CONNECTIONS prior to the completion of the project, OCFS Commissioner
Johnson suspended implementation of the application in the spring of 1998.
Governor Pataki convened a Panel in January of 1999 to review the issues and to
make recommendations for the future of CONNECTIONS. The Governor’s Panel recommended that an
independent contractor conduct an analysis and reassessment. The CONNECTIONS Reassessment Report (
Although it was
determined that CONNECTIONS did not meet a significant number of users needs
nor did it meet all SACWIS requirements, Maximus found that the State could
leverage the investments that have been made in the design, development, and
modifications to CONNECTIONS to build a more responsive SACWIS system for New
York State. Based upon these findings,
the report recommended that the State move forward with the development of
critically needed family focused Case Management and Financial Management
functionality using new application architecture.
II.
PROJECT SCOPE
The current New York
State SACWIS System, known as CONNECTIONS is in production statewide and
includes the following components:
·
Child
Protective Services (CPS) Intake
·
Child
Protective Services (CPS) Investigation
·
Resource
Directory & Foster Adoptive Home Development (FAD)
The completion of the
CONNECTIONS includes three main components:
·
Child Welfare
Case Management Functionality
·
Child Welfare
Financial Management
·
Management
Information and SACWIS Reporting
A. Target Population
The system developed under this charter will apply to
children of
B. New Functionality:
Child Welfare
Case Management (Phase I)
The new system will enable the structured entry and tracking of data to support decision-making at the individual and case level. The system changes are being made to promote the dual goals of safety and permanency for all children. It will also provide aggregate case management information for agency management and monitoring of these goals.
The
Case Management Phase will define security functionality for the system and
provide for the creation of a child welfare services case in CONNECTIONS. It
will allow for the cases currently in CONNECTIONS CPS production (cases that
entered the system through SCR Intake and progressed through CPS Investigation)
to be completed as Child Welfare Services cases. It will also provide Services intake for
families requesting voluntary services, including the determination of
programmatic eligibility for Preventive Services. This phase will also provide a comprehensive
electronic case record for Child Welfare cases, which will include all
assessment and service planning activity currently encompassed in the Uniform
Case Record (UCR). To maintain consistency, the Services Case Record will be
modeled after the previously developed multi-tabbed format of the Child
Protective Record Summary (CPRS) and Foster Adoptive Home Development (FAD)
Record Summary. It will allow easy direct entry of information into the
Services Record Summary.
The major Child Welfare Case Management components are as follows.
·
Services Intake
The Services Intake process must record and track requests
for services outside of the CPS track, including requests for information and
referrals. Capacity is needed to record the requestor/referral source, enter
basic demographic information, access Person search functionality, record the
presenting issue in a narrative format, and record the decision to open for
services, complete a pre-service evaluation, or close the intake. If a case is
not opened, the system must capture the reason for this.
The Services Intake process must support the determination
of programmatic eligibility for Mandated Preventive Services and provide for a
multiple level (local district and voluntary agency) approval process for
determinations. It is also necessary to retain a proper audit trail of
information after determining programmatic ineligibility. The Services Intake must also allow for
optional recording and tracking of Information and Referral Requests and
provide access to the Resource Directory.
The system should produce an Application for Services with
pre-filled information from the Services Intake and provide for the date the
Services Application is signed by the family to be recorded in the system. This date is the Case Initiation Date driving
regulatory timelines for prescribed service activities. The system must also a record of whether the
Application for Services was accepted, withdrawn or denied, and support a
supervisory approval of the Services Intake.
·
Creation of Services Case
The
Services Case process must support the capacity to record and document the
provision of any child welfare service that is made available to any child or
family coming into the system for whom Uniform Case Records (UCRs) are
required. The Services Case is the shell
that holds all of the case assessment, service planning and fiscal
activities. This includes maintaining
information concerning programmatic eligibility, and the documentation of
progress notes and contacts.
·
Uniform Case Record
The system must support the workers need to assess and plan with families continuously over the life of a case, making modifications as appropriate to changing circumstances, evolving needs, and lessons learned from past approaches. A multi-tabbed approach will be used for recording of discrete components of the UCR. Workers must be able to work on components in any sequence and to update individual components as needed until supervisory approval. They should be able to see separate components concurrently on screen. (For example, they should be able to view assessment information while completing the services plan). All relevant components must be completed before bundling and sending a services plan for supervisory approval as required by law/regulation at specified points in a case. The system must provide for a multiple level approval process. Components must be printable separately and as a formatted complete UCR, which can be read and signed by the family. The system must provide workers with the appropriate UCR components to be completed as determined by the type of case and the prescribed OCFS timetable. The system must alert workers to coming due and overdue UCRs.
UCR functionality is as follows:
·
Assessment
·
Case Assessment/Safety Review
The Safety Review/Update is a summary of the significant case events that have occurred since the last UCR was completed. The system will include two formats for Case Update, one for CPS track and one for Services cases. The CPS version will include a Child Safety Review of safety related behaviors, conditions and interventions since the last UCR, a Safety Decision (“Safe” or “Unsafe”) as to current safety of the child, identification of key protecting factors if safe, or description of safety interventions to be taken if unsafe. A narrative summary of non-safety related case events and casework activities and progress towards identified goals since the last UCR will be included. The Services version will include a narrative summary of the significant case events related to the presenting problem or current concerns that have occurred since the last UCR was completed, including behaviors and/or events that may have threatened the safety of the child, family or community, and a description of the actions, services and casework activities that have been taken and progress towards identified goals. It will also identify key protecting factors currently present and describe how these support the present safety of the child, family or community, either at home or in the current placement.
·
Risk Assessment
Workers need to assess all indicated CPS cases for the risk
of future abuse or maltreatment according to a prescribed timetable. The
assessment identifies the present case level risk of future abuse/maltreatment
and is used to assess case progress and develop the Service Plan. The system must support an actuarial risk
assessment model, which will include the automated calculation of a risk score
according to a worker’s assessment of research based risk factors. The system must support policy and
discretionary overrides of the system calculated score. It must also capture narrative information
regarding individual risk factors and overrides.
·
Family Assessment
The
system must support the workers need to assess overall family functioning,
needs, and concerns, not just the risk factors for future abuse or
maltreatment. It is critical that the assessment includes a primary focus on
family strengths and resources and be done in partnership with the family. The
system must support worker awareness of family strengths throughout the
assessment process in order to avoid exclusive emphasis on the family’s
deficits and problems. Because a goal of assessment is to help the family
identify family strengths and abilities that can be used to build an effective
solution to the identified risks or problem and help families meet their needs,
the system will need to include both narrative fields and easy to use
assessment tools to facilitate the State’s strength-based approach to child
welfare practice. Areas assessed might include basic needs, parenting
skills, ability to cope with stress, availability of social supports, family
interaction, communication /interpersonal skills, child’s response to
caregiver, child’s behavior, academic performance, and caretaker’s motivation.
Significant family history/background should be evaluated and be recorded in the system.
·
Services Plan
The
system must support the workers need to establish and record one of 12
Permanency Planning Goals (PPG) and Anticipated Completion Date (ACD) for each
child for whom child welfare services are authorized. The PPG is key to
achieving the dual goals of safety and permanency for children. It should drive
provided services and casework activities. Any changes in PPG must be explained
and recorded. The system must support
the identification of one or more Services Program Choices (Preventive
Non-Mandated, Preventive Mandated, Placement, and/or Protective) and record the
reason or need for placement or mandated preventive services if selected. PPGs,
ACDs, Program Choices and Reasons are currently entered into CCRS legacy system
and need to be captured by the new system.
The
system must record the narrative Services Plan that describes the actions
planned to meet the most important needs of the family so that the PPG can be
achieved. The Service Plan is divided into narrative statements of identified
needs or problems that will be addressed during the current plan period,
identification of associated risk elements, a statement of the demonstrable
desired outcome for each area to be addressed by the next planned reassessment,
and a brief description of both the specific family/child activities and
service provider activities to achieve/support the specified outcomes. An
individual plan component is completed for each area to be addressed.
The
system must support workers in the development of service plans in conjunction
with the family that address the needs/concerns/risks identified in the Risk
and Family Assessments, pursue family and caseworker identified goals, and
utilize, support and supplement family strengths and resources in the planned
activities to achieve outcomes appropriate to the PPG. The system must document
the level of involvement of parent(s) and children in development of the
service plan. Planning conferences and service plan reviews must be documented,
including the date held and listing of all participants by title/role. Plan
Amendments must be supported at specified points in the child welfare services
case through the use of alerts and ticklers, as well as allowed at any point in
the services case.
·
Placement Issues
Although
Placement will not be implemented until Phase II, the system must support
recording of placement issues in phase I so that foster care workers can use
the Family Case in CONNECTIONS to document placement issues in UCRs rather than
continue to use the current standalone UCRs. These placement issues will be
grouped under a separate tab. The system must support documentation of specific
items by individual child in all placement cases, including the Appropriateness
of Placement, the Family / Child Visitation Plan, Concurrent Planning, Progress
towards Permanency, and Discharge Planning. A combination of yes/no questions,
space for comments/explanations, and narrative fields must also be supported.
The system must also support the collection and maintenance of data regarding
all Foster Care Status Changes.
·
Progress
Notes / Casework Contacts
Progress notes are an ongoing narrative log of all the
activities, meetings and general information about a child or family to whom
services are being provided. Notes are entered throughout the life of a report
or case. The system must support the users need to record and maintain progress
notes on a daily basis in a uniform, easy to use manner. The system must also
support the need to sort and access the narrative log of activities performed
during the life of an intake, report or services case. Caseworkers are the most
likely group to be recording progress notes into a CONNECTIONS case, but it is
also possible that a unit clerical person or a supervisor may be entering some
notes. The system must implement a standard UCR Progress Note form, which is a
free form narrative, combined with data fields to capture critical case contact
information. Required data fields will be kept to a minimum with optional
fields available to enhance sorting capacity. Notes will be able to be updated,
by anyone with the appropriate security profile, until they are approved and
frozen. It will be necessary to have multiple templates to capture primary
worker and secondary worker notes in separate locations. While each may read the others notes, the
system must not allow any cross update capability.
Child
Welfare Case & Financial Management (Phase II)
The new system will support the authorization, payment and claiming of child welfare services as well as providing aggregate financial management information for Office of Children and Family Services management and monitoring.
·
Foster Care
Placement
The system must allow for the recording of
all required information related to the placement and movement of a child in a
foster or adoptive home. Search
capabilities must the capability to locate a resource and program that will
best meet the needs of the child. All
demographic data, medical data and information concerning legal authority for
the placement that is required for AFCARS reporting must be captured by the
system. The level of difficulty (LOD),
any modifiers to the LOD and any emergency situations must be supported by the
system in order to identify proper payment levels. All legal activities related
to permanency need to be supported by the system. If the child is moved to another foster home
or congregate care facility, the system must track all movements of the child
including absences. Additionally, the
system must maintain an historical record of when and where the child was in
foster care. The system must be able to record a surrender agreement and record
all adoption milestones. Registration
for adoption photo listing must also be supported.
·
Services
Authorization
The services authorization process begins
with the caseworker identifying that a client has a need for a particular
purchased service or needs to receive particular goods. Examples of services authorized are
counseling, housekeeping, and camp fees.
The caseworker could be from a voluntary agency or from a local
district. The system must support the
entry of services to the system through a services authorization referral. Detailed information concerning where the
service will be purchased, the schedule for service and the amount of services
authorized must also be supported. This
detailed information would translate the needs identified in the referral
process into the codes and data elements that would be forwarded to the payment
system. In some locations, the local district caseworker would enter the
detailed information. However, in the
majority of districts, support staff who would not necessarily have a role in
the case would enter the detailed data.
For on-going foster care placement, recurring clothing, and on-going
adoption subsidy payments, no authorization processing should be required. The authorization records required by the
payment system should be created as a by-product of the foster care placement
and adoption dialogs.
·
Adoption
Subsidy
The adoption subsidy process begins with a
review to determine if the child is eligible for an adoption subsidy. To derive the proper payment amount, the
level of difficulty and any rate modifiers must be recorded. There also must be an interface to the New
York State Adoption Services. Once an
adoption is finalized, and if an adoption subsidy payment is established, the
information must be passed to Benefit Issuance and Control System (BICS) for
payment generation.
·
Eligibility
To meet SACWIS requirements, the system
must not just record financial eligibility, as is performed in the current
system, but must allow for the actual determination of financial
eligibility. Based upon previously
entered data and additional information entered, the system must determine the
eligibility of a foster care child for IV-E, TANF-EAF, TANF-200% of poverty and
Medical Assistance. For in-home
preventive cases, the system must determine eligibility for TANF-EAF and
TANF-200% of poverty. Once the
eligibility of the child or family is determined, it should be forwarded to the
payment system. As payment are generated
for that child or family, the payment system must use the eligibility data
received to derive the most beneficial claiming situation for each expenditure.
·
Rate Table
Entry for Voluntary Agencies (legacy system change)
The current legacy financial management
system (BICS) provides rate table entry and rate table processing for direct
foster care and adoption subsidies, but does not provide the same functionality
for voluntary agency payments. The
ability to enter payment rates for all programs, for all voluntary agencies
must be developed. The system must
support the entry of contract, as well as Maximum State Aid Rates (MSAR). Contract rates will be entered by the local
districts and will identify the amount that will be paid. The MSAR will be entered by State staff and
will determine the maximum amount that local districts will receive in State
and Federal reimbursement. Rates must be
entered for all program areas for all voluntary agencies that will receive
foster care payments. In addition, there
must be the ability to enter multiple occurrences of the same program type for
a particular resource. Rates are
required to be entered for foster care room & board payments.
·
Rate
Processing in Voucher Processing (legacy system change)
During voucher processing for rate-based
payments, the system must access the contracted rates that were entered through
the new rates setting functionality and automatically derive the payment amount
based on an analysis of the rates and the days in care. The vendor’s rates for the particular program
would be accessed along with the authorized service type to determine the
amount of payment. After the payment
calculation, the system must review the derived amount against the MSAR. The portion over the MSAR must be identified
as non-reimbursable.
·
Monthly Batch
and Retroactive Claiming (legacy system change)
The financial management system must
include voluntary agencies in the monthly claiming batch job that determines
all special and retroactive claiming.
Any foster care homes that are not certified, any child without proper
legal authority for placement, and any payment amounts over the MSAR must be
identified as non-reimbursable (NR). The
system must also retain the reason for the NR situation to allow this
information to be displayed on the user requested Non-Reimbursable report. If an emergency situation exists, the system
must not allow IV-E claiming but must determine the maximum amount reimbursable
from other funding sources. In addition,
any retroactive claiming category changes to previously issued expenditures
would be identified and reported on a supplemental composite roll used for
supplemental claiming. Changes in
eligibility must be determined derived from changes to the eligibility
module. When a change is made, the
information must be passed to BICS and any payments within the changed period
must have an adjustment record created.
The adjustment record would be reflected on the supplemental composite
roll.
·
Monthly
Retroactive Payments (legacy system change)
Any increase to the payment rates or any
change to the placement of the child that would result in additional payment to
voluntary agencies must be included in the payment system. These changes could result from changes to
the vendor’s daily rates as well as changes in the individual child’s level of
difficulty or a correction in child’s date of birth. The system must be enhanced so that a voucher
is automatically created based on changes resulting in a change in the amount
(more or less) of monies due the voluntary agency.
Child
Welfare SACWIS Compliance (Phase III)
The new system must
support contracts for services and an accounts receivable subsystem as well as
bring the CONNECTIONS system into full SACWIS reporting compliance.
·
Contracts
In certain
preventive services situations, and in some foster care situations, local
districts establish a contract with a voluntary agency to perform certain
services. Contracts are usually entered
for a one-year period, but could be for a shorter or longer period of
time. A dollar amount with various cost
allocation breakouts must be provided to local districts to allow them to enter
the contract. Inquiry against the
entered and updated contract data needs to be available to local districts and
to the related voluntary agency. Local
Districts need the ability to modify the dollar amount within the contracts and
also the period of the contract. The contract
information will be used by BICS voucher processing to determine that the
dollar amount of the each cost allocation breakout is not exceeded. To be clear, the contracts referenced in this
module are not for regular room and board provided by voluntary agencies. Room and Board rates are established through
the rate setting functionality.
·
Accounts
Receivable
To meet SACWIS requirements, the financial
management portion of the system must contain an Accounts Receivable
component. Accounts Receivable is the
tracking of overpayment to providers and, when appropriate, the reduction of
future payments based on the debt owed.
An Accounts Receivable module must also track trust accounts established
for individuals. Monies received from
external sources may be added to a clients account or may be processed as a
refund in repayment of room and board.
·
Management
Information and SACWIS Reporting
The
new system will meet the SACWIS reporting requirements. Required AFCARS and NCANDS information will
be entered into the system, and resultant data will be extracted. The system
must support AFCARS/NCANDS data requirements as well as the needs of system
users. The deficiency of Federally
required data elements should not prevent workers from documenting case events
such as foster care placement or services authorizations. The system will be designed to support a
summary page that lists all AFCARS/NCANDS data that has been captured for a
given case. The page will also identify
data that has not yet been recorded.
Workers could use these screens to facilitate the entry of the missing
data.
Management
reporting needs must be met primarily though the Data Warehouse. Some reports will be part of the application,
but most information needs will be processed using the Data Warehouse. The Data Warehouse will replace the previous
Management Reporting module referred to as CONNECTIONS Release 5. The system will support linkages to other
data sources for informational needs; for example, the Welfare Reform Tracking
System (WRTS) Reporting System, will done through the Data Warehouse.
C.
Replacement Legacy Systems,
Components of Legacy Systems and
Databases
The system developed
under this charter will replace the functions currently provided by OCFS’s
legacy mainframe systems and databases, including the following:
·
CCRS
·
WMS Services –
Child Welfare Services (Foster Care, Adoption, Preventive & Protective
Services)
Replacement of the legacy systems or
components of legacy systems will require conversion of legacy child welfare
data into the CONNECTIONS application.
Other standalone systems will be
identified for potential integration.
E. Interfaces
or Links to Other Systems
The following interfaces are envisioned between CONNECTIONS and other New York State systems:
·
System Interface to Benefit Issuance and Control System
(BICS)
Additionally,
the system will interface with the Department Of Family Assistance’s statewide
payment system, BICS for the processing of vouchers, payments and claims
associated with services, placements and adoption subsidies authorized in
CONNECTIONS.
·
System Interface to Non Services Welfare Management System
(WMS)
Federal
SACWIS requirements mandate an electronic interface between the CONNECTIONS and
Non Services WMS. The expected results
of the interface are to:
(1)
allow for the
exchange of common data, an example of such information is financial
information necessary for eligibility;
(2)
accept and
process updated or new case data and;
(3)
identify
potential duplicate payments.
·
System Interface to Child Support Management System (CSMS)
Federal
SACWIS requirements mandate an electronic interface between CONNECTIONS and
CSMS (Title IV-D System). The expected
results of the interface are to:
(1)
Allow for the
establishment of a child support case
(2)
Identify child
support resources for Title IV-E children
(3)
Allow for the
exchange of common data;
(4)
Capture data
needed for the Adoption and Foster Care Analysis System (AFCARS)
(5)
Provide the
CSMS system with information about the current foster care payment
(6)
Accurately
record child support collections on appropriate Federal reports.
The
interface may also be used to access the use of the Federal Parent Locator
Service on behalf of children in foster care to identify non-custodial parents
to facilitate permanency-planning activities.
·
System Interface to Medicaid Management Information System
(MMIS)
Federal
SACWIS requirements mandate an electronic interface between CONNECTIONS and
MMIS (Title XIX System). The expected
results of the interface are to:
(1)
Provide for
the exchange of information needed by the State Medicaid system to calculate
and track Medicaid eligibility for children in foster care;
(2)
Allow for the
automatic exchange of common data; and
(3)
Capture the
data necessary for AFCARS.
·
System Interface to New York State Adoption Services Systems
(NYSAS)
Currently,
NYSAS systems provide automated searching capabilities for adoptive resources
and for the required photo listing of children when freed for adoption. An interface will be built between
CONNECTIONS and these systems to avoid duplicative data entry and promote
programmatic efficiencies.
·
System Interface to Division of Rehabilitative Services
(DRS) KIDS System
KIDS
is the automated system that supports case management, tracking and facility
support for youth placed in the Custody of the Commissioner of OCFS. An interface will need to be developed for
the exchange of common and necessary information regarding mutual clients
including the capture of AFCARS information on Title IV-E eligible youth.
E.
User Groups and Functionality
The system needs to effectively and efficiently support over 18,000 State, local and voluntary agency child welfare staff in responding
·
To over
140,000 child abuse and maltreatment reports received annually on families
involving approximately 270,000 children
·
To over 80,000
families in need of Preventive and
aftercare services
·
To over 48,000
foster care and juvenile delinquent children currently in out-of-home care
F. System
Features
·
Graphical User Interface (GUI)
The
front end of the system to be developed will utilize a graphical user interface
(e.g., point and click field access, drop down menus, scrollable fields for
narrative entry, radio buttons) to support intuitive screens with flexible
sequencing and completeness and accuracy checking.
·
Security
The
system must facilitate maximum information sharing within a security system
that assures that only appropriate staff has access to information. The system
should have locally modifiable access profiles that control the following types
of rights: create, read, update, delete and print. Profiles need to be dynamic
based upon a worker’s function and/or location and a need to know. The Security architecture needs to be independent
of the application system to provide maximum flexibility and optimal
performance.
Security
features will also include auditing of access and modification of certain
database tables.
G. Infrastructure
The scope of
this project proposes the use of a much more open system interface capability
than the existing CONNECTIONS Infrastructure, while leveraging and reusing
critical technical components such as the upgraded desktops and CITRIX
Servers.
The Technical
Team will recommend and assess the system architecture to determine if existing
network capacity can support acceptable performance standards (response time
and number of users). If not, the
technical team will recommend an alternative architecture or identify required
upgrading for Office of Children and Family Services review and approval.
Testing
will assess whether the system meets established performance criteria.
III. ASSUMPTIONS
The following
assumptions have been made in defining the scope and resource requirements of
this project. Successful completion of
this project is dependent on the following assumptions:
·
There will be
top level Executive support for the project, and it will remain a high priority
within the Office of Children and Family Services.
·
The Office of
Children and Family Services will provide and maintain project staff (program
and technical) throughout the life of the project with continued support after
implementation.
·
The Office of
Children and Family Services will provide adequate budgetary support, which can
be accessed in a timely fashion for all items included in the approved project
budget.
·
The Office of
Children and Family Services will avoid unnecessary delays in the processing of
proposed Policies, and the Project must exist within this Policy
environment. Additionally, the Project
can move forward only within the means given it, and must have the flexibility
to accommodate changes in Policy.
.
·
The Office For
Technology will provide and maintain staff and technical support for the
technical infrastructure including the Network, Data Center and Enterprise Help
desk.
·
The
CONNECTIONS Project Executive Steering Committee will provide overall guidance
and leadership to the project.
·
The
CONNECTIONS Project Management Committee will provide management coordination,
integration of the work group efforts, issue resolution and prioritization for
the changes to Connections. The
Committee has prioritized and developed the schedule for implementation for the
changes to the production application and will continue to set the direction
for the new development efforts.
·
The
CONNECTIONS Project will adhere to a System Development Life Cycle (SDLC)
approach so that the product delivered to the end user meets the business need
and is compatible with their work operation.
Any deviation from the prescribed SDLC will be explained and justified.
·
The
CONNECTIONS Project will support an independent Quality Assurance contractor,
as well as employ internal quality assurance practices within the project to
identify project risks and develop and implement appropriate that risk
mitigation strategies.
·
The
CONNECTIONS Project, in conjunction with the Office of Children and Family
Services, will assure that training, sufficient to operate the system as
designed, will be available to all end users.
This will include, at a minimum:
-
Basic PC
skills training and
-
Understanding
by each user of how to use the system to accomplish their assigned tasks.
IV. DEVELOPMENT APPROACH
A.
Development Approach and
Methodology
The functionality of
the system, identified in the Project scope section, will be organized into
logical components, and deployed so as to have the least operational impact on
end users.
A System Development Life Cycle (SDLC) approach to system
development will be adhered to for the project so that the product delivered to
the end user meets the business need and is compatible with their work
operation. The life cycle will include
User Requirements definition, Logical and Detail Design, Code Construction,
Product Test, User Acceptance Test, Training, Communications and
Implementation. Please see Appendix A for a complete description of the SDLC.
·
Requirements Design and Construction
Program staff, in concert with the functional workgroups,
will define user requirements. In order to most effectively maximize the time
commitment of the workgroups, requirements will be presented with a proposed
solution for their review and comment.
The application development process will be more iterative
than in past CONNECTIONS development efforts through the use of rapid
development tools that allow for prototyping.
OCFS Within each functional component, design and development will
overlap. Screen prototypes will be started after design has begun, but before
it is complete. This will allow both
OCFS Program staff and end users to weigh in early in the design effort with
suggestions for functional improvements and enhancements. Database will be modified incrementally with
design of each functional component. A
standard object oriented Com+ design methodology will be employed, supported by
non-proprietary automated development tools. Implementation of each functional
component will be phased in based on priority and logical fit within the
development effort, as determined by the Project Team.
This approach will provide for faster delivery of quality
based functionality and more easily managed implementation.
·
Testing
Effective
system testing begins in the requirements phase where errors can be detected
and corrected on paper rather than after coding. Any/all organizations responsible for testing
must be involved in application development, from the requirements phase
through final sign off if testing is to be successful.
Unit
test is a discrete test of each individual item created or modified in an
application. It is usually done by the developer organization. This phase of testing is largely limited to
verifying that each individual component accepts and/or processes information
as defined in the requirements. Once all individual items have been fully
tested and deficiencies corrected, they are assembled into the final
application and passed on to product test.
Product
test is a wrap up test of the final, complete application, usually done within
the developer organization, prior to releasing it to the requester/user for
final user acceptance testing. The two major objectives of this phase of
testing are the verification that the individual components “fit” together and
that they operate as defined in the requirements. It is in this phase that full
regression testing is initiated, some of which can be supported by automated
testing tools. Again, product test is
usually done under the auspices of the developer organization and largely
focused on the technical operation of the application. Once product test is complete and
deficiencies are corrected, the final application is released for user
acceptance testing.
User
acceptance testing should reside in the customer/requester organization and
focus on how the functional application “fits” the customer’s needs rather than
on its technical operation. The desired outcome is not only to verify ascertain
that the application operates as defined in requirements/specifications but
that it efficiently supports the administrative/organizational structures and
business functions found throughout the customer community. It has as its
principal mission, the “exercise” of the application in both system and
administrative structures/environments analogous to those in place throughout
the customer community. It should be done
by staff familiar with customer business functions and administrative
structure, using test plans/scenarios encompassing the types of situations
expected in the “real world”. Secondarily, this phase of testing provides final
chances to identify technical problems not previously addressed and refer them
to the developer organization for repair/re-test. While automated tools have a
place in this phase of testing so that the application arrives in the user test
environment intact, the actual test depends on “hands on” flexibility and
creativity.
·
Implementation, Training and Change
Management
The Connections
Project will provide training and technical assistance to users to assist in
the full implementation of Connections through a comprehensive strategy that is
based on the following principles:
· The project will develop a coordinated and integrated approach to support the field with input from the workgroups and regional implementation staff activities.
- The project will support a phased
implementation approach.
- The project will provide support
for workers using a variety of tools and methods in order for them to
operate the system in order for them to operate the system and incorporate
it with their daily workflow.
- The project will provide support
to assist districts/agencies to assess basic skills and readiness of users
well in advance of implementation.
- The project will address Change
Management issues and necessary changes in local practice, process and
operation prior to implementation of new functional components.
B. Development Deliverables and Schedule
The
following schedule provides preliminary, high level dates for key stages
and deliverables for this project:
Phase I: Case mangement Development Schedule
|
SDLC Step |
Start Date |
End Date |
|
Requirements |
|
|
|
Logical Design |
|
|
|
Detailed Design |
|
|
|
Software Construction |
|
|
|
Product Testing (planning…execution) |
|
|
|
User Acceptance Testing (planning…execution) |
|
|
|
Field Testing (execution) |
|
|
|
Production |
|
|
|
Implementation (Planning, training, & post implementation) |
|
|
Phase II: Case & Finanacial management Development Schedule
|
SDLC Step |
Start Date |
End Date |
|
Requirements |
|
|
|
Logical Design |
|
|
|
Detailed Design |
|
|
|
Software Construction |
|
|
|
Product Testing (planning…execution) |
|
|
|
User Acceptance Testing (planning…execution) |
|
|
|
Field Testing (execution) |
|
|
Production
|
|
|
|
Implementation (planning, training, post implementation) |
|
|
PHASE III SACWIS COMPLIANCE Development Schedule
|
SDLC Step |
Start Date |
End Date |
|
Requirements |
|
|
|
Logical Design |
|
|
|
Detailed Design |
|
|
|
Software Construction |
|
|
|
Product Testing |
|
|
|
User Acceptance Testing |
|
|
|
Field Testing |
|
|
|
Production (SACWIS Compliance) |
|
|
|
Implementation |
|
|
V.
PRELIMINARY
PROJECT BUDGET
The following is the preliminary project budget for CONNECTIONS Case and Financial Management. This cost estimate will be refined and may change as user requirements are more precisely defined, as the project plan is updated to reflect final user requirements, and as the system design and architecture are more fully specified.
VI.
PROJECT ROLES AND RESPONSIBILITIES
Team/Office
|
Role
|
Responsibilities
|
Members
|
Executive Steering Committee
|
Executive Direction and Support
|
·
Resolve
issues ·
Approve and
direct Policy changes |
·
Executive
Sponsor ·
Directors
LDSS ·
Directors
Voluntary Agencies ·
OCFS CONNECTIONS
Project Directors ·
OCFS Budget ·
NYS DOB |
Management Committee
|
Provide management coordination
|
·
Oversee
integration of the work group efforts, ·
Resolve
issues ·
Prioritize
changes to CONNECTIONS |
·
OCFS Project
Managers ·
Local
District Managers ·
Voluntary
Agency managers |
Project team
|
OCFS Requirements Team
|
·
Define
and coordinate the programmatic and
user aspects of the project user requirements
|
·
OCFS Program
Staff |
Implementation Team
|
·
Define and
coordinate communication, training and implementation aspects of the project. |
·
OCFS Program
Staff |
|
Testing team
|
·
Develop test strategies, plans
and schedules ·
Executing and documenting user
tests |
·
OCFS Program
Staff
|
|
Application Development Team
|
·
Develop and
coordinate the Application Development team and technical/support team so
that the system is delivered within project constraints (budget and schedule)
|
·
OCFS IT
Staff ·
Contract
Staff |
|
Management
Reporting
|
·
Design and develop management
& SACWIS reporting capability |
·
OCFS Program
Staff ·
Contract
Staff |
|
Technical
Team
|
·
Interface with Office for
Technology (OFT) representative(s) from the Data Center and Human Services
Network to coordinate hardware and software required for development and
production. |
·
OCFS IT
Staff ·
Contract Staff |
|
End User Workgroups
|
·
Defining user requirements, logical and detailed design for case
management functionality. ·
Assisting with user acceptance testing. ·
Identification of change management strategies and training needs and
supports. ·
Identification of the need for subgroups to work on specific issues
or development |
Subject area experts from ·
LDSS, ·
Voluntary Agencies, ·
OCFS Program, ·
OCFS Policy, ·
CONNECTIONS Project Staff |
|
QA Consultant
|
·
Project Management Support ·
Technical and Functional
Alternative Support ·
Evaluation of proposed Technical
Solutions ·
Independent Validation and
Verification of the adherence to SDLC ·
Identify Project risks and
identify & evaluate risk mitigation strategies |
Maximus Consulting
|
|
OFT
|
Data Center Open Systems
|
·
Define, procure and maintain all
hardware and software required
software for development, testing, training and production; |
·
OFT Open
Systems Staff
|
Network Architecture
|
·
Develop and implement any
required upgrades to network so that the existing network provides required
connectivity and capacity |
·
OFT Network
Staff
|
|
Enterprise Help Desk
|
·
Develop and
implement 24 x 7 help desk support plan and materials |
·
OFT Help
Desk Staff
|
|
Network Security
|
·
Develop and implement Security Plan for the
System to be developed
|
·
OFT Security
Staff
|
Resource Notes
The
project will require support staff sufficient to facilitate the project’s
progress.
·
At all phases
of the development, the CONNECTIONS Project Staff will solicit and coordinate
end-user involvement through the use of facilitated workgroups with end-user participation. It is expected that a representative from a
Local District and Voluntary Agency will be chosen to co-lead the workgroup.
The leads will report periodically to the Management Committee regarding the
direction and decisions of the workgroup.
Issues that cannot be resolved by consensus within the workgroup will be
presented for resolution to the Connections Management Committee. Either through on-site participation or via
electronic exchanges or conference calls, end users will be involved in all
phases of project development.
·
Consultants,
if needed, will be contracted with to perform functions that cannot be provided
by state staff. However, contract staff
will be directly supervised and report to State staff
·
Management,
program, and technical staff will be available for involvement, as needed.
·
Ongoing
technical support will be available for the project team and for the final
implemented system.
·
Equipment and
supplies needed for the project team to conduct business will be available
Signed
By:
_____________________________ _____________________________
Zack
Zambri Larry
Brown
CONNECTIONS Project Director Deputy Commissioner
NYS OCFS NYS
OCFS
Div of Development &
Prevention Services
In
signing this project we are indicating our support for the completion of the
CONNECTIONS Project, specifically the implementation of the Case and Financial
Management components of the system, confirming our agreement with the project
practices, goals, and objectives as they are stated, and expressing our
confidence that the project will meet both program and technical requirements
through adherence to the charter.