Project Payment Template Template - DOC

Document Sample
Project Payment Template Template - DOC Powered By Docstoc
					                                    eXPRS Implementation Strategy


                             Template Examples Disclaimer

Unless otherwise specifically stated, the information contained herein is
made available to the public by the Department of Human Services, Office
of Information Services, Project Management Office for use as an example
of template content information and may not reflect the realities of an actual
project. The intent of the template example is to assist an individual
creating a new document using the PMO standard template.

Neither the DHS, OIS, PMO nor any other agency or entities thereof,
assumes any legal liability or responsibility for the accuracy, completeness,
or usefulness of any information, product or process disclosed in these
examples.

Reference herein to any specific commercial product, process, service by
trade name, trademark, manufacturer, or otherwise, does not constitute or
imply its endorsement, recommendation, or favoring by the PMO or any
entities thereof.

The views and opinions of the originators expressed therein do not
necessarily state or reflect those of the DHS, OIS, PMO or any agency or
entities thereof.




Page 1 of 9                                                     Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc
                                       eXPRS Implementation Strategy



             Oregon Department of Human Services
                 Office of Information Services




      Express Payment & Reporting System (eXPRS)
                Implementation Strategy
                                   Approval Date: 09/18/2002



                    Initiation                 Planning




                                 Controlling              Executing



                                                                      Verify Requirements
                                                                      Conceptual Design
                                               Closing                Functional Design
                                                                      System Construction
                                                                      Implementation




                                   Purpose of the Document
The purpose of the Implementation Strategy is to define and recommend the potential
implementation scenarios based on the principles and considerations defined by the
Project Steering Committee (i.e., cost, duration, functionality, etc…)

The Implementation Strategy includes decisions for design alternatives and potential
releases to be used in creating a definitive implementation plan.




Page 2 of 9                                               Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc
                                  eXPRS Implementation Strategy


                              Document Change Activity
The following is a record of the changes that have occurred on this document from the
time of its original approval
#   Change Description                                                      Author       Date




Page 3 of 9                                               Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc
                                    eXPRS Implementation Strategy


1  Implementation Strategy ...................................................................... 5
 1.1   Design Recommendations ............................................................ 5
 1.2   Release Strategy .......................................................................... 6
2 Design Alternatives - Detail.................................................................. 7
 2.1   Make or Buy Analysis ................................................................... 7
 2.2   Interface with Client Index System (CI) ......................................... 8
 2.3   Interface with Contract Status & Timing (CSTAT) ......................... 8
 2.4   eXPRS Development Environment ............................................... 9
 2.5   Scenario #1 – Replace Rbase first................................................ 9
 2.6   Scenario #2 – Deliver system with one ‘big-bang’ release ............ 9
 2.7   Scenario #3 – Deliver system using phased approach ................. 9




Page 4 of 9                                                     Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc
                                      eXPRS Implementation Strategy



1 IMPLEMENTATION STRATEGY
The primary constraint for implementing a payment system is that implementation must
occur at the start of a fiscal year. Implementing a new payment system requires a
period of parallel operations with the existing system as well as using a pilot to improve
product quality prior to general rollout.

Implementing a payment system also requires corresponding changes in the contracts
that the payments are based on as well as coordination with changes in accounting and
budget code structures. Therefore, the project recommends adopting the following
implementation schedule:

                                  eXPRS Payment & Reporting System
                                      Implementation Schedule

       Jun 2002      Sep 2002     Jan 2003        Jun 2003             Jan 2004 Apr 2004         Jul 2004
    Plan Approved   R1 Defined   R1 Designed   R1 in Production         R2 Pilot R2 Parallel   R2 Switchover




 May 2002                                                                                        Jul 2004


1.1 Design Recommendations

Each design recommendation is detailed in the remaining sections of this report.

     Build eXPRS using internal development staff to reduce overall cost and duration of
      satisfying the business need.

     Build eXPRS using a phased approach to build the system in multiple releases to
      make business improvements faster and timelier.

     Build eXPRS outside of Curam to meet schedule constraints while collaborating with
      MMIS and Transformation Project to centralize functionality that should be
      performed at an enterprise level.

     Build external interface with Client Index System (CI) to centrally manage client
      information.

     Build external interface with Contract Status Tracking & Timing (CSTAT) to share
      contract information.

     Build eXPRS using Cold Fusion (presentation tier), Websphere (application tier) and
      DB2U (database tier)


Page 5 of 9                                                     Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc
                                    eXPRS Implementation Strategy


1.2 Release Strategy

Release 1 benefits include: increase payment accuracy, improve reconciliation, reduce
manual input, prove the feasibility of the technical architecture, and introduce change to
system stakeholders early in the development process.

All conversion and replacement work entails complex business logic and requires close
monitoring for risk mitigation. The project will define a transition process for both
releases in the Implementation Plan.

Release 1 functionality: Client and Provider Enrollments, Prior Authorization (subset),
System Administration (subset). Release 1 work includes:

   Replace the Rbase Interface database with an external DB2 Interface to SFMA.
    Note: this work must be prioritized to accommodate schedule constraints.

   Replace the client and provider enrollment and termination paper forms for Client
    Process Monitoring System (CPMS) with an electronic version that is entered
    electronically into eXPRS and manually/batch uploaded into CPMS.

   Replace the Terminations and Service Adjustment Records (TSAR) form with web-
    based screens.

   Convert unique client identifiers from CPMS to the CI system and ensure security
    requirements for access to client information (all DD clients, all A&D clients, and only
    Community Mental Health clients).

   Develop web-based forms for Providers to record and verify service delivery for
    exception tracking. This functionality will replace the Provider Financial Statement
    (PFS) in Release 2.

   Build a process to transfer Provider Enrollment data from eXPRS to CPMS with a
    one-time conversion and an ongoing manual process to stay synchronized using a
    crosswalk.

   Build the technical infrastructure for system development and operations

   Develop a role-based security model that authorizes at the individual level.

   Provide training to DHS, Counties, and Providers for the new web-based interface.

Release 2 functionality: Payment Request, Payment Process, Prior Authorization
(complete), System Administration (complete). Release 2 work includes:

   Replace the Provider Financial Statement (PFS) with web-based screens.

   Develop all remaining Prior Authorization and System Administration functionality


Page 6 of 9                                                     Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc
                                    eXPRS Implementation Strategy


   Develop all remaining external interfaces necessary to operate system

   Develop an interface with the HIPAA translator and HIPAA compliant Claim form
    (837) to ensure HIPAA compliance.

   Replace the remaining Rbase databases

   Build the Reporting capabilities described in the Business Requirements (i.e.,
    System Reports, Federal Reports, Tax Reporting, etc…)

   Provide training to DHS, Counties, and Providers for the new payment process.

2 DESIGN ALTERNATIVES - DETAIL
2.1 Make or Buy Analysis

10 accounting based systems were reviewed for reuse opportunity from the States of
Oregon, Arizona, Louisiana, and Nevada, as well as commercial products (i.e., Oregon
Dept. of Forestry, Oregon Youth Authority, Curam, and Anasazi).
Alternative       Pros                                         Cons
New         Best fit to Business Requirements.                 Introducing new technology may
Development Greatest productivity gains in                     present unforeseen risk.
            shortest timeframe.
                  Cost savings with new capabilities.
Purchase & Compliance with DHS system                          Timing (i.e., Mar 2003 HTML
Customize – architecture (if selected).                        release,   Business    Feasibility
CURAM                                                          complete in Oct 2002).
                                                               Requires                 substantial
                                                               customization     (i.e.,   payment
                                                               processing functionality).
                                                               Financial portion has not been
                                                               implemented within the United
                                                               States (has within UK).
                                                               Payment processing would be
                                                               outside of Curam anyway.
                                                               Duration of procurement process
                                                               likely to delay schedule.
Purchase & Some Oregon Counties & Providers                    Requires software installation and
Customize – are using other Anasazi modules                    maintenance on all desktops.
Anasazi     and would be able to share                         User screens are complicated and
            information and interface easily.                  require extensive training.


Page 7 of 9                                                     Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc
                                    eXPRS Implementation Strategy



Alternative       Pros                                         Cons
                                                               All     customization     and
                                                               maintenance must be performed
                                                               by Anasazi.
                                                               Requires an annual maintenance
                                                               agreement and fee.
                                                               Has only been implemented on a
                                                               county level, no experience with
                                                               statewide implementation.
                                                               Duration of procurement process
                                                               likely to delay schedule.
Transfer  & Meets many of the eXPRS                            Technology not supported in DHS
Customize – business requirements including                    standards (Small Talk and Oracle
OYA         having    provider   and     client                Database).
            enrollment and a pre-authorization                 System is not web-enabled.
            component.                                         Requires installation of software
                                                               on to the user’s desktop.
2.2 Interface with Client Index System (CI)
Alternative           Pros                                      Cons
Interface   with Compliance       with     agency Requires testing in new technical
Client    Index directive    to   provide     client environment.
System (CI)      information across services.        Work is necessary from both CI
                 Reuse of functionality and data.    and eXPRS staff.
                      No    anticipated        performance Security for non-DHS users not
                      impact on CI.                        in place.
2.3 Interface with Contract Status & Timing (CSTAT)
Alternative           Pros                                      Cons
Interface   with Compliance with agency directive               CFAA contract not currently in
Contract Status to provide centralized contract                 CSTAT.
and       Timing management.                                    Data at summary level               not
(CSTAT)                                                         sufficient for eXPRS needs.
                                                                CSTAT resources may not be
                                                                available to implement required
                                                                changes.
                                                                Direct interface may present
                                                                performance issues (based on
                                                                different technologies).


Page 8 of 9                                                     Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc
                                    eXPRS Implementation Strategy


2.4 eXPRS Development Environment
Alternative             Pros                                     Cons
Cold Fusion only        Faster development                       Reuse of business logic
                        Quick learning curve           Oregon.gov                 is   converting   to
                        Currently used in e-Government Websphere
                        web portal
Websphere only          Reuse of business logic                  Difficult to learn
                        Same technology            as    DAS Significant training requirements
                        payment manager
Cold        Fusion Rapid screen development and Increased tool cost
(presentation tier) provides reuse of business
and Websphere logic.
(application tier)

2.5 Scenario #1 – Replace Rbase first

There are three Rbase databases in the existing system: Community Payments,
Community Contracts, and the Statewide Financial Management Application (SFMA)
Interface. The databases are in different Rbase versions, each with bugs that are no
longer being patched through vendor upgrades.

Rbase is not supported by vendors and there are few people within OIS that can
maintain the Rbase databases. Workstations running Rbase are beginning to fail as a
result of infrastructure changes made (i.e., operating system upgrades).

Replacing the Community Payments and Community Contracts databases requires that
the new payment process design is complete. Based on the schedule constraints, a
new payment process will not be implemented until July 2004.

2.6 Scenario #2 – Deliver system with one ‘big-bang’ release

This scenario will delay the delivery of benefits and improvements until the end of the
project and is not recommended.

2.7 Scenario #3 – Deliver system using phased approach

A phased approach to build a system in multiple releases makes business
improvements faster and timelier and as a result is likely to foster increased customer
satisfaction and support throughout the life of the project.

A new payment system must be implemented in whole. Facilitated work sessions were
held to identify the functionality for each release, based on the associated benefits and
schedule constraints.


Page 9 of 9                                                     Revise Date: 7/14/2011 3:35:00 PM
C:\Docstoc\Working\pdf\d512685c-9e45-4041-8d2f-f67913ce038f.doc

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:45
posted:7/14/2011
language:English
pages:9
Description: Project Payment Template Template document sample