CMS Initiation Final

New Case Management
System (CMS) Project
Initiation Document
January 27, 2011

DOCUMENT HISTORY
Date Version Editor Changes

Jan. 6, 2011 1.0 D. Chase Initial draft
Jan. 12, 2011 1.1 D. Chase • Fixed various grammatical & text items
• Updated Success Measures
• Updated Project Scope
• Updated Assumptions & Constraints
• Updated Project Roles & Responsibilities
• Appendix A - MOSTD Oversight Severity &
Risk Analysis
Jan. 20, 2011 1.2 D. Chase • Updated Schedule
• Updated Work Products
• Updated Resources
• Appendix B – Project Governance
Jan. 27, 2011 1.3 D. Chase • Found & replaced grammatical issues
New Case Management System Project
Initiation Document
TABLE OF CONTENTS
1. Project Statement ..................................................................................................................................... 1
2. Business Case ........................................................................................................................................... 1
3. Objectives ................................................................................................................................................. 3
4. Scope ......................................................................................................................................................... 3
5. Assumptions ............................................................................................................................................. 4
6. Risk Factors .............................................................................................................................................. 5
7. Cost, Schedule, and Resources .............................................................................................................. 6
8. Work Products ......................................................................................................................................... 9
9. Project Organization ............................................................................................................................. 10
10. Success Measures ................................................................................................................................... 13
11. Agreement............................................................................................................................................... 14
Appendix A. MOSTD Oversight Severity & Risk Analysis ...................................................................... 15
Appendix B. New UI CMS Governance ...................................................................................................... 18

Initiation Document
The purpose of this document is to provide an overview of the New Case Management System
Project and describe the resources needed to complete the objectives outlined. This document will
be used to guide additional planning tasks and project activities.
1. PROJECT STATEMENT
The Office of Administrative Hearings (OAH) is an independent state agency that conducts more
than 70,000 impartial administrative hearings per year for state and local government agencies.
Three separate case management systems are currently in place at OAH. Each system is completely
independent, that is separate databases, separate reporting, and separate data entry. This project will
focus on the unemployment insurance cases but will be developed in a manner that is scalable
enough to be used for the other caseloads as funds are secured.
The project will not only develop a new case management system (CMS) but will create new
standardized processes and procedures for the handling of cases at OAH. OAH will look to
streamline processes and procedures to maximize staff effectiveness and minimize costs such as
time to process an appeal and the paper produced. Currently support staff spend a significant
amount of time preparing and copying documents that go into an appeal file.
The goal is to create a system that provides flexibility to track appeals as they progress through the
case management lifecycle; be scalable to allow for modifications when necessary (i.e. new ESD
program issue codes); and reflect efficient business processes. The new system will increase
effectiveness in time and resources so OAH can be nimble and mobile in meeting UI caseload
demands. The new CMS will be a system for the UI caseload that will become the model for all
OAH case management systems. The new CMS will be a centralized system that provides safe,
secure, and complete access to all necessary data wherever there is an Internet access in case ALJs
cannot access the office. Our future will be that we can literally do our jobs where ever we have
access to the system.
2. BUSINESS CASE
Currently, for the Unemployment Insurance (UI) caseload OAH relies on a system called ACTS –
Appeal Case Tracking System. ACTS was created about 15 years ago. At the time ACTS was
recognized as a novel and cutting edge UI case tracking system. Recently OAH hired an
independent consulting firm to conduct an efficiency assessment. The result was that ACTS is
beyond its life expectancy and puts OAH at risk. Some of the risks identified are:
• Ineffective business processes which result in poor use of staff resources and materials. The
current system requires staff to complete several manual processes (e.g., assembly, sorting &
copying files) and uses WordPerfect macros to create the various case documents. All
processes are paper intensive and dependent on paper records. Consequently UI processes
and practices vary between OAH offices and even within offices. There is no system
documentation and as a result much of the operational knowledge resides “in the heads” of
key staff within an office on how to use ACTS.
January 27, 2011 Version 1.2 Page 1

Initiation Document
• No data standards which results in poor and/or lost data. There are no data input standards
which mean that incorrect data or that some critical data fields are empty. There are too
many data tables and the linkage between tables is confusing. Little or no database
documentation (data dictionary or data definitions, or data flow templates) exists. ACTS has
been repeatedly upgraded, modified, and changed over the years and no documentation
exists.
• Uses outdated software (Borland Paradox & WordPerfect) as core system components
which may result in lost data. Borland Paradox uses older database architecture which is
limited in record and data processing (e.g., record locking, record indexing, sequencing, etc.).
No technical support is available for Borland Paradox or WordPerfect.
• ACTS is a document creation system not a case management or tracking system which may
result in lost or misplaced records. There is no way to determine what step in the appeal
process a case is at within ACTS. Again, cases are tracked “in the heads” of key support
staff through operational knowledge. No audit log exists on modifications or changes made
on data entered into the system.
• ACTS is a distributed database which may result in lost or misplaced data and ineffective use
of staff resources. Each OAH field office has its own database. Each day, field office data
are merged with a centralized agency core system. This takes 0.5 of an ITS4 FTE to
accomplish.
A new case management system will offer OAH an opportunity to change business processes and
become more efficient in processing appeals. For example, all intake and scheduling can occur as a
centralized system function, or have the ability to determine a case complexity based on the data
input which may reduce the time necessary for a hearing. Changing business processes requires
strong management support as well as training and communications.
At the core of any case management system is a comprehensive document and information
management system. Rather than trying to develop such a system from “scratch,” the new CMS will
be based on the Microsoft SharePoint 2010 platform. This will enable the new CMS to use common
and Washington state government standard business tools such as Microsoft Word, Microsoft Outlook,
Microsoft SQL server and other tools. The system will also make maximum use of established
technologies at OAH such as Citrix.
At the completion of this project, we will have a system that:

• Includes all necessary data relevant to the case;
• Is stable and secure;
• Includes a component for digital hearing record to be included in the case file;
• Includes data validation and error checking;
• Uses standardized forms and documents;
• Provides data that is necessary to create reports for reporting performance measures;
• Does integrated scheduling using Microsoft Outlook.

Initiation Document
3. OBJECTIVES
Several project objectives have been identified with this project, these are:
1. Development of a UI CMS that will have:
Standardized processes & procedures through standardized forms and documents, data
entry, and data templates;
Production of electronic documents, electronic document transfer, and digital archiving;
Integrated scheduling using MS Outlook;
Safe and secure data and files; and,
Improved performance reporting.
2. Implementation of a UI CMS by March, 2012. Implementation will include the following
OAH staff training components:
New CMS processes and procedures;
Using MS Outlook for scheduling;
Using MS Word for creating documents; and,
Using MS SharePoint for retrieving documents and reports.
3. Acquisition, installation, and implementation of all necessary technology components (e.g.,
hardware & software) that is in accordance with DIS standards and procedures.
4. Good coordination, cooperation and communication with OAH staff, vendors, and client
agencies through:
Communications plan that identifies medium, methods, approval, audiences;
Risk, issue, & event tracking and logging;
Clearly defined roles & responsibilities; and,
Periodic & routine meetings and sessions.
5. Project completion by March, 2012 that is within the timelines and within budget.
6. UI CMS will serve as a foundation for future case management systems within OAH.
4. SCOPE
All of OAH will be affected by this project.
Components within the scope of this project are:

• How OAH processes UI appeals as well as how OAH receives and transfers data and
information between ESD and OAH.
• Defining CMS data elements & schema to be consistent with state enterprise data
framework standards.
• Current system maintenance activities with current agency systems – ACTS, HATSS, &
CATS. Improvements, upgrades, or major changes to these systems should be minimized.
Components not within the scope of this project are:

• Automatic or integrated data transfer between ESD systems (Telecenters and/or
Commissioner’s Review Office).
• Billing or time accounting system to replace current OAH systems, e.g., TMS.

Initiation Document
5. ASSUMPTIONS & CONSTRAINTS
Project activities and deliverables are developed with the following assumptions in mind:
• A “test lab” environment will be created and used to mimic the current OAH environment.
The test lab will allow for evaluating technology and for providing a learning “rip-and-tear”
environment. Further “experimentation” will be done in the test lab.
• Technology will be implemented in ‘phases’ (e.g., “Test Lab,” “Pre-Production,” and
“Production”).
• Current existing infrastructure and technology equipment found in field offices (application
servers, Ethernet switches, workstations, etc.) are satisfactory.
• Whenever possible, commercially available solutions (hardware and software) will be used.
• Security and access solutions will be compatible and within established DIS and ISB security
standards.
• Acquisition of services and equipment will be compatible and within established DIS &
OFM purchasing guidelines.
• CMS will be designed around using Microsoft SharePoint 2010 and the suite of Microsoft Office
2010 products (e.g., Outlook, Word, Excel, InfoPath, etc.)
• Project planning will be done using Microsoft Project.
• Integration with current OAH systems will be done using existing OAH IT resources.
• Necessary technology training, if needed, will be made available.
• Staff involved will continue to fulfill their existing duties; however, required resources
(whether existing team members or fill-ins) will be committed to this project as agreed upon
to ensure successful implementation.
• All work will be accomplished within budget allocation as identified in the Supplemental
Budget Request.
The following project activities and deliverables are developed with the following constraints in
mind:
• This project was identified by DIS MOSTD (Management Oversight & Strategic
Technology Direction) as Level 1 project (see appendix A). This required elimination of
automatic & integrated data transfer processes between ESD & OAH.
• Anticipated work load peaks will occur within the agency that will potentially compete for
this project’s resources.
• Operational constraints & agency issues, as well as workload peaks by staff need to be
accommodated (e.g., resource availability).
• Scheduled leave or holidays may limit resource availability at times.
• Project Schedule will identify many tasks that have dependencies which if not met, will cause
a ripple effect downward of the project schedule.
• No alternate resources have been approved should staff become unavailable to perform
their tasks.

Initiation Document
6. RISK FACTORS
It is critical to the success of this project that potential risks be identified and communicated, and a
risk management strategy is in place for each phase of the project. The following table identifies
major risks and mitigation strategies. A separate, more detailed Risk Management Matrix will be
developed and incorporated into OAH’s Risk Registry.
Elements for
Success Risks Leading to Failure Mitigation Strategies
Staff Availability • Key staff may not be • Communicate resources required and gain
available to effectively assurances that staff resources will be made
determine requirements and available in a timely manner.
perform development and
testing.
Manageable • Requirements and • Develop and follow an agreed upon change
Scope requested changes exceed management process.
to scope of the project. • The ‘CMS Steering Committee’ will guide and
keep the project within scope and determine
business requirements.
Planning & • Too aggressive timelines • Use the CMS Steering Committee to guide
coordination • Poorly defined roles & project timelines & milestones
responsibilities • Clearly defined roles & responsibilities
• Poorly defined milestones • Project manager monitors project progress and
coordinate resources
• Track & log issues and events
Knowledge, • Poor CMS design. • Develop a staff training plan.
consulting & • Poor technology (e.g., • Research and investigate agency case
advice SharePoint) knowledge and management techniques and strategies.
understanding. • Coordinate and use existing SharePoint and
• Poor implementation CMS knowledge developed in other state
strategies. agencies.
• Develop and follow a good testing plan.
• Establish good rapport with key business users
and agency experts
• Use the CMS Steering Committee to guide the
project and determine business requirements.
Communication • Poor communication and • Develop and follow an agreed upon change
& coordination coordination with OAH management process.
employees. • Develop and follow a communication plan.
• Poor communication and • Document meeting minutes.
coordination with vendor.
Training • Inadequate technical • Develop and follow a training plan
training • Ensure training made available
• Inadequate staff training • Use IT Liaisons

Initiation Document
7. COST, SCHEDULE, AND RESOURCES
Cost
The total available federal funding awarded by the US DOL for this project is $489,742. The
following table shows a breakdown of the costs by major activity.
Category Cost % Confidence

Equipment (hardware & software) $34,400 90%
CMS Training $20,640 80%
External Consulting & Programming $403,022 80%
Quality Assurance $31,680 70%
TOTAL $489,742
Schedule
The following table provides an overview of major activities and completion dates. A detailed
project schedule will be developed separately to provide additional detail regarding tasks, resources
and dates.
Major Activities and Tasks Dates

UI CMS Project Initiation October 2010 -
• Identify and document project requirements January 2011
• Identify project governance
• Review other agencies case management systems
• Communication plan
Determine Project Requirements October 2010 -
• Identify hardware & software requirements February 2011
• Identify business requirements through business workgroups
• Map & describe business work flows
• Identify data elements
• Test consolidated business processes
Vendor selection & initial development February 2011 -
• Complete data dictionary & data structures May 2011
• Finalize consolidate business processes
• Complete Software Requirements Specifications (SRS) document
• Complete vendor work order
• Interview & select vendor, contract with vendor
Initial UI CMS review, testing & evaluation June 2011 –
• Prototype & early version (alpha) UI CMS development October 2011
• Testing, evaluation, recommendations, modifications with selected users
• Project Team & UI CMS Steering Committee approval of version changes
• Coordinate changes with vendor and on-going development
• Create test UI CMS environment, ensure hardware & software are operational
• Present pre-production (beta) version to stakeholders

Initiation Document

Final UI CMS testing & preparation for implementation October 2011 –
• Evaluate pre-production UI CMS (beta) and ensure data & functional accuracy December 2011
• Testing, evaluation, modifications, with expanded group of selected users
• Project Team & UI CMS Steering Committee approval of final UI CMS version
• Coordinate changes, modifications, and updates with vendor
• Present UI CMS to ADCs & Office Managers
• Identify training materials and plans
• Create implementation plan
• Create pre-production UI CMS (technical environment) for extensive testing &
functionality
Quality Assurance December 2011 –
• Hire private vendor to perform “light” quality assurance assessment of CMS February 2012
• Prepare for quality assurance - ensure all requirements documentation &
change orders are assembled
• Coordinate with vendor quality assurance
• Review quality assurance report from vendor
UI CMS Implementation March 2012 –
• Perform training at each field office April 2012
• Coordinate with each field office for UI CMS installation
• Provide extra local IT & UI CMS support
• Lessons learned at each local office post-implementation
UI CMS Lessons Learned & Project wrap-up May 2012
• Coordinate with vendor on final UI CMS issues
• Meet with various UI CMS workgroups to do Lessons Learned
• Project Team & Steering Committee approval
• Identify with the vendor and Steering Committee what possible future
improvements can be made for future versions.

Initiation Document
Resources
The following table lists agency resources expected to participate in the project. The “Est. Project
Involvement” column identifies the estimated percent of time the resource is “dedicated” to the
project; since most staff will be participating in the project concurrently with their current job
responsibilities and duties. This percentage estimate is the average for the life-time (estimated 20
months) of the project. Consequently, there may be times when the project resource may
periodically be 100% involved with the project and other times involved very little or not at all.
Est. Project
Resource Project Role
Involvement
Lorraine Lee Project Sponsor, GMAP Project Team 30%
Lead, & CMS Steering Committee
Don Chase Project Manager 50%
Tarisse Injerd Project Coordinator 90%
Bill Dodge Business Project Team Lead 90%
Loree Hawkens Technical Team Lead 50%
Stephanie Croom-Williams Stakeholder Team Lead & CMS Steering 20%
Committee
Virgil Sweeney Time-Keeping BMV Lead & CMS 20%
Steering Committee
Patti Latsch Performance BMV Lead & CMS Steering 20%
Committee
Justin Hansen SharePoint & Technical Team member 50%
John Morgan Technical Team member 30%
Frank Mighetto Technical Team member & multiple 30%
workgroup member
IT Liaisons IT Liaisons 10%
BMV Team Leads BMV Team Leads 15%
BMV & Ad hoc Wrkgrp members BMV & Ad hoc Workgroup members 10%
ADCs ADCs 5%

Initiation Document
8. WORK PRODUCTS
The following work products will be produced.
Major Activity Work Products

CMS Project • Project initiation document
Initiation • Communications plan
• Project schedule
• Risk management plan
• Project team roles and responsibilities document
• Project governance document
Determine Project • Business Activities Document
Requirements • Business work flow drawing
• Data screens indicating elements as determined from business workgroups
• Agency glossary relating to terminology and measures
Vendor Selection & • Data dictionary
Initial Development • Software Requirements Specifications document
• Vendor work request & work order
• Technical flow charts
• Sample or proposed screen views
Initial CMS Review, • Prototype and Alpha CMS releases (for each)
Testing & o Test plan (Implementation, audience, timeline & milestones)
Evaluation o Testing criteria
• Summary of change orders
• Issue & tracking log
Final CMS Testing • Beta CMS release
& Preparation For o Test plan (Implementation, audience, timeline & milestones)
Implementation o Testing criteria
• Summary of change orders, issue & tracking log
• CMS presentation for agency staff and stakeholders
o PowerPoint presentation
o Demonstration of system
• Agency CMS Training plan
• Pre-Implementation plan
Quality Assurance • Vendor work request & work order
• Vendor Quality Assurance report
CMS • CMS documentation – instructions, guides, how-tos, FAQs
Implementation o Policy and procedures relating to use of CMS
• Lessons learned per each local office
• Summary of issue & tracking log
CMS Lessons • Post Implementation Review document (Lessons Learned)
Learned & Project • Vendor summary report
Wrap-Up • Next version recommendations

Initiation Document
9. PROJECT ORGANIZATION
The project governance design can be found in Appendix B.
Not all project positions are defined below, only those that have significant roles and responsibilities
in the project and directly influence the success of the project.
Project Sponsor – Lorraine Lee

The Project Sponsor represents the business processes being addressed by the project and is
ultimately accountable for the project’s success. The Project Sponsor must be committed to change,
must have budget authority over the project, and must be willing to mandate business process
alignment within the program and/or Agency where necessary.
Project Sponsor will:

• Ensure commitment from the organization to participate in the project
• Ensure that political and organizational obstacles to project success are addressed in a timely
manner
• Ensure funding and other resources are available for the duration of the project
• Resolve outstanding project personnel and resource issues
• Supervise and direct the Project Manager, Project Coordinator, and Business Team Lead
Project Steering Committee – Lorraine Lee, Patti Latsch, Stephanie Croom-Williams, Virgil
Sweeney
The Project Steering Committee guides the project and ensures project and business objectives are
being met. The Project Steering Committee must be committed to understanding project
requirements and balance them with business requirements.
Project Steering Committee members will:

manner
• Ensure resources are available for the duration of the project
• Approve project plans
• Approve major project changes (scope, schedule, etc.)
• Approve final reports (deliverables) from all project phases
• Resolve outstanding project operational and functional issues
• Approve recommendations made by the Project Teams

Initiation Document
Project Manager – Don Chase

The Project Manager has the technical managerial oversight of the project and, along with the
Project Sponsor, has overall responsibility for the project. The Project Manager has the basic task of
integrating the efforts of both the user and technical teams in developing the CMS. The Project
Manager assigns the technical project deliverables to specific project personnel and tracks their
progress in accordance with the project plan. The Project Manager is the prime planner, organizer,
and team leader for the project. The Project Manager works very closely with the Project Sponsor
in the development and management of the project from start to finish.
The Project Manager will:

• Plan & control the project
• Direct and coordinate project resources which may include assigning tasks and deliverables
• Approval of project documents, materials, presentations, and status reports
• Provide management oversight of system development tasks
• Be the primary agency contact with the vendor, developers, consultants
• Prepare project work plans & work breakdown structures
• Approve technical system design and specifications, and technical deliverables such as
diagrams and specifications to be used by developers
• Produce project deliverables in accordance with the SDLC project management
methodology
• Verify that design and technical decisions are consistent with the OAH standards and
strategies and compatible with those of the state as a whole
Project Coordinator – Tarisse Injerd

The Project Coordinator coordinates project meetings, workgroups, training and other
communications are completed timely and within project specifications. The Project Coordinator is
the prime communicator, facilitator, and organizer for the project. The Project Coordinator works
very closely with the Project Manager in the development of the project.
The Project Coordinator will:

• Assist in the creation and preparation of project documents and status reports.
• Ensures that the project communications plan is being followed.
• Work with the Project Manager that project milestones, tasks, and events are being met
timely and successfully.
• Coordinates and ensures project resources are available for meetings, tasks, and other project
items.
• Facilitate and lead various meetings (e.g., Steering Committee, training, Lessons Learned,
testing) and workgroup sessions
• Assist in the development of user testing criteria and user testing
• Coordinate, facilitate, and/or lead user testing
• Coordinate, facilitate, and/or lead user training
• Coordinate and facilitate CMS implementation
• Assist and help create technical deliverables such as diagrams and specifications to be used
by developers
• Manage & publish content for the SharePoint CMS sites and Inside OAH

Initiation Document
Business Team Lead – Bill Dodge

The Business Team Lead coordinates BMV workgroups, and ad-hoc workgroups for the project and
is the lead ensuring that business elements are included in the CMS. The Business Team Lead works
very closely with the Project Manager and Project Coordinator in the development of the project.
The Business Team Lead will:

• Ensure that the communications plan is being followed.
• Coordinate and ensure project resources are available for meetings, tasks, and other project
items.
• Assist in facilitation & organization of BMV Workgroup & Ad hoc workgroups, user testing
and user training meetings
• Assist in user testing
• Assist in user training
• Assist in CMS implementation
by developers
• Assist in managing & publishing content for the SharePoint CMS sites – Steering Committee
& Workgroups.
• Verify that CMS design and deliverables are consistent with the OAH legal standards and
Technical Lead – Loree Hawkens

The Technical Lead provides the linkage between the technical needs of the project and business
requirements. The Technical Lead is the technical subject matter expert who understands the
detailed business aspects of the project and will provide a clear understanding as to what
functionality the system must provide to the potential system users. The Technical Lead is expected
to work very closely with the Project Manager and Project Sponsor, and interfaces continually with
others working on the project.
Technical Network Lead will:

• Provide technical oversight on the CMS technical system
• Define the basic concepts of the system to meet needed functionality
• Determine information and system requirements
• Perform and assign technical tasks, as needed
• Prepare test plans and test data, and coordinate and conduct system testing
• Define and document operational procedures

Initiation Document
10. SUCCESS MEASURES
The following factors will be used to guide and measure the success of this project.
• Project concludes with all identified work plan components (tasks and milestones)
successfully completed within the scheduled time and budget.
• All project purchases (hardware, software, consulting, development, and training) are
completed by 09/30/12.
• Good system performance;
o Measures:
No. of help desk calls;
Server & database system uptime of greater than 99.9%; and,
No record of complaints or issues.
• Good coordination between OAH and DIS.
o Measures:
Written evaluation written by DIS MOSTD;
Periodic meetings with meeting minutes; and,
• Good coordination between OAH and ESD.
o Measures:
Written evaluation written by ESD and ESD Commissioners Review Office;
• Good coordination between OAH and vendors;
o Measures:
Closing vendor evaluation;
• Good coordination between CMS Project Team and OAH employees/customers;
o Measures:
Closing survey & evaluation with a cumulative score above 3.3 (1 poor – 5
excellent) in the following categories:
Testing;
Training;
Communication methods; and,
Implementation.
• The CMS system receives a cumulative approval rating by OAH staff equal to or greater
than 3.3 (1 poor – 5 excellent) in the following areas:
o Functionality; and,
o Design, layout & appearance.
• CMS project plan milestones met within 90% of the time as set forth in the project plan.

Initiation Document
11. AGREEMENT
The following signatures by the Project Sponsor and Project Manager indicate acceptance and
approval of the Project Initiation document as written.
Lorraine Lee, Chief Administrative Law Don Chase, CIO & Project Manager
Judge

Initiation Document
Appendix A. – MOSTD Oversight Severity & Risk Analysis
Severity Level Criteria

The severity matrix assesses the proposed project’s impact on citizens and state operations, its visibility
to stakeholders, and the consequences of project failure.
Categories
Impact on Visibility Impact on State Failure or Nil

Levels Clients Operations Consequences
High • Direct contact • Highly visible to • Statewide or • Inability to meet

with citizens, public, trading multiple agency legislative mandate
political partners, political involvement / or agency mission.
subdivisions, and subdivisions and impact. • Loss of significant
service providers Legislature. • Initial mainframe federal funding.
– including • Likely subject to acquisitions or
benefits hearings. network
payments and • System acquisitions.
transactions. processes
sensitive /
confidential data
(e.g. medical,
SSN, credit card
#’s).
• Indirect impacts • Some visibility to • Multiple • Potential failure of
Medium on citizens the Legislature, divisions or aging systems.
through trading partners, programs
management or public the within agency.
systems that system / program
support supports.
decisions that • May be subject to
are viewed as legislative hearing.
important by the
public.
• Access by
citizens for
information &
research
purposes.
• Agency • Internal agency • Single division. • Loss of opportunity
Low operations only. only. • Improve or for improved
expand existing service delivery or
networks or efficiency.
mainframes with • Failure to resolve
similar customer service
technology. complaints or
requests.

Initiation Document
Risk Level Criteria

The risk matrix measures the impact of the project on the organization, the effort needed to complete the
project, the stability of the proposed technology, and agency preparedness.
Categories
Functional Impact Development Effort Technology Capability &

on Business & Resources Management
Processes or
Levels Rules
• Significant change • Over $5 million. • Emerging. • Minimal executive
High to business rules. • Development and • Unproven. sponsorship.
• Replacement of a implementation • Two or more of the following • Agency uses ad-hoc
mission critical exceeds 24 months.* are new for agency technology processes.
system. • Requires a second staff or integrator, or are new to • Agency and/or vendor
• Multiple decision package. the agency architecture: track record suggests
organizations programming language; inability to mitigate
involved. operating systems; database risk on project
• Requires extensive * Clock starts after products; development tools; requiring a given level
and substantial job feasibility study or data communications of development effort.
training for work project approval and technology.
groups. release of funding. • Requires PKI certificate.
• Complex architecture – greater
than 2 tier.
• Moderate change to • Under $5 million • New in agency with 3rd party • Executive sponsor
Medium business rules. but over agency expertise and knowledge knowledgeable but
• Major enhancement delegated transfer. not actively engaged.
or moderate change authority. • One of the technologies listed • System integrator
of mission critical • 12 to 24 months for above is new for agency under contract with
system. development and development staff. agency technical
• Medium complexity implementation. * participation.
business • Agency and/or vendor
process(es). * Clock starts after record indicates good
• Requires moderate feasibility study or level of success but
job training. project approval and without the structure
release of funding. for repeatability.
• Insignificant or no • Within agency • Standard, proven agency • Strong executive

Low change to delegated authority. technology. sponsorship.
business rules. • Under 12 months • Agency and vendor
• Low complexity for development have strong ability to
business and mitigate risk on a
process(es). implementation.* development project.
• Some job training • Project staff uses
could be required. documented and
* Clock starts after repeatable processes
feasibility study or for tracking status,
project approval and problems, and
release of funding. change.
• Agency or vendor is
CMM Level 3
equivalent or above.

Initiation Document
Project Approval and Oversight Matrix

The level of approval and oversight required on a given project is determined through an assessment of
project risk and severity:
Level Level Level

High Severity
2 2 3
Level Level Level
Medium Severity
1 2 2
Level Level Level
Low Severity
1 1 1
Low Risk Medium Risk High Risk

Initiation Document

New Case Management
System (CMS) Project
Initiation Document
January 27, 2011

DOCUMENT HISTORY
Date Version Editor Changes

Jan. 6, 2011 1.0 D. Chase Initial draft
Jan. 12, 2011 1.1 D. Chase • Fixed various grammatical & text items
• Updated Project Scope
• Updated Assumptions & Constraints
• Updated Project Roles & Responsibilities
• Appendix A - MOSTD Oversight Severity &
Risk Analysis
Jan. 20, 2011 1.2 D. Chase • Updated Schedule
• Updated Work Products
• Appendix B – Project Governance
Jan. 27, 2011 1.3 D. Chase • Found & replaced grammatical issues
Initiation Document
TABLE OF CONTENTS
1. Project Statement ..................................................................................................................................... 1
2. Business Case ........................................................................................................................................... 1
3. Objectives ................................................................................................................................................. 3
4. Scope ......................................................................................................................................................... 3
5. Assumptions ............................................................................................................................................. 4
6. Risk Factors .............................................................................................................................................. 5
7. Cost, Schedule, and Resources .............................................................................................................. 6
8. Work Products ......................................................................................................................................... 9
9. Project Organization ............................................................................................................................. 10
10. Success Measures ................................................................................................................................... 13
11. Agreement............................................................................................................................................... 14
Appendix A. MOSTD Oversight Severity & Risk Analysis ...................................................................... 15
Appendix B. New UI CMS Governance ...................................................................................................... 18

Initiation Document
The purpose of this document is to provide an overview of the New Case Management System
Project and describe the resources needed to complete the objectives outlined. This document will
be used to guide additional planning tasks and project activities.
1. PROJECT STATEMENT
The Office of Administrative Hearings (OAH) is an independent state agency that conducts more
than 70,000 impartial administrative hearings per year for state and local government agencies.
Three separate case management systems are currently in place at OAH. Each system is completely
independent, that is separate databases, separate reporting, and separate data entry. This project will
focus on the unemployment insurance cases but will be developed in a manner that is scalable
enough to be used for the other caseloads as funds are secured.
The project will not only develop a new case management system (CMS) but will create new
standardized processes and procedures for the handling of cases at OAH. OAH will look to
streamline processes and procedures to maximize staff effectiveness and minimize costs such as
time to process an appeal and the paper produced. Currently support staff spend a significant
amount of time preparing and copying documents that go into an appeal file.
The goal is to create a system that provides flexibility to track appeals as they progress through the
case management lifecycle; be scalable to allow for modifications when necessary (i.e. new ESD
program issue codes); and reflect efficient business processes. The new system will increase
effectiveness in time and resources so OAH can be nimble and mobile in meeting UI caseload
demands. The new CMS will be a system for the UI caseload that will become the model for all
OAH case management systems. The new CMS will be a centralized system that provides safe,
secure, and complete access to all necessary data wherever there is an Internet access in case ALJs
cannot access the office. Our future will be that we can literally do our jobs where ever we have
access to the system.
2. BUSINESS CASE
Currently, for the Unemployment Insurance (UI) caseload OAH relies on a system called ACTS –
Appeal Case Tracking System. ACTS was created about 15 years ago. At the time ACTS was
recognized as a novel and cutting edge UI case tracking system. Recently OAH hired an
independent consulting firm to conduct an efficiency assessment. The result was that ACTS is
beyond its life expectancy and puts OAH at risk. Some of the risks identified are:
• Ineffective business processes which result in poor use of staff resources and materials. The
current system requires staff to complete several manual processes (e.g., assembly, sorting &
copying files) and uses WordPerfect macros to create the various case documents. All
processes are paper intensive and dependent on paper records. Consequently UI processes
and practices vary between OAH offices and even within offices. There is no system
documentation and as a result much of the operational knowledge resides “in the heads” of
key staff within an office on how to use ACTS.

Initiation Document
• No data standards which results in poor and/or lost data. There are no data input standards
which mean that incorrect data or that some critical data fields are empty. There are too
many data tables and the linkage between tables is confusing. Little or no database
documentation (data dictionary or data definitions, or data flow templates) exists. ACTS has
been repeatedly upgraded, modified, and changed over the years and no documentation
exists.
• Uses outdated software (Borland Paradox & WordPerfect) as core system components
which may result in lost data. Borland Paradox uses older database architecture which is
limited in record and data processing (e.g., record locking, record indexing, sequencing, etc.).
No technical support is available for Borland Paradox or WordPerfect.
• ACTS is a document creation system not a case management or tracking system which may
result in lost or misplaced records. There is no way to determine what step in the appeal
process a case is at within ACTS. Again, cases are tracked “in the heads” of key support
staff through operational knowledge. No audit log exists on modifications or changes made
on data entered into the system.
• ACTS is a distributed database which may result in lost or misplaced data and ineffective use
of staff resources. Each OAH field office has its own database. Each day, field office data
are merged with a centralized agency core system. This takes 0.5 of an ITS4 FTE to
accomplish.
A new case management system will offer OAH an opportunity to change business processes and
become more efficient in processing appeals. For example, all intake and scheduling can occur as a
centralized system function, or have the ability to determine a case complexity based on the data
input which may reduce the time necessary for a hearing. Changing business processes requires
strong management support as well as training and communications.
At the core of any case management system is a comprehensive document and information
management system. Rather than trying to develop such a system from “scratch,” the new CMS will
be based on the Microsoft SharePoint 2010 platform. This will enable the new CMS to use common
and Washington state government standard business tools such as Microsoft Word, Microsoft Outlook,
Microsoft SQL server and other tools. The system will also make maximum use of established
technologies at OAH such as Citrix.
At the completion of this project, we will have a system that:

• Includes all necessary data relevant to the case;
• Is stable and secure;
• Includes a component for digital hearing record to be included in the case file;
• Includes data validation and error checking;
• Uses standardized forms and documents;
• Provides data that is necessary to create reports for reporting performance measures;
• Does integrated scheduling using Microsoft Outlook.

Initiation Document
3. OBJECTIVES
Several project objectives have been identified with this project, these are:
1. Development of a UI CMS that will have:
Standardized processes & procedures through standardized forms and documents, data
entry, and data templates;
Production of electronic documents, electronic document transfer, and digital archiving;
Integrated scheduling using MS Outlook;
Safe and secure data and files; and,
Improved performance reporting.
2. Implementation of a UI CMS by March, 2012. Implementation will include the following
OAH staff training components:
New CMS processes and procedures;
Using MS Outlook for scheduling;
Using MS Word for creating documents; and,
Using MS SharePoint for retrieving documents and reports.
3. Acquisition, installation, and implementation of all necessary technology components (e.g.,
hardware & software) that is in accordance with DIS standards and procedures.
4. Good coordination, cooperation and communication with OAH staff, vendors, and client
agencies through:
Communications plan that identifies medium, methods, approval, audiences;
Risk, issue, & event tracking and logging;
Clearly defined roles & responsibilities; and,
Periodic & routine meetings and sessions.
5. Project completion by March, 2012 that is within the timelines and within budget.
6. UI CMS will serve as a foundation for future case management systems within OAH.
4. SCOPE
All of OAH will be affected by this project.
Components within the scope of this project are:

• How OAH processes UI appeals as well as how OAH receives and transfers data and
information between ESD and OAH.
• Defining CMS data elements & schema to be consistent with state enterprise data
framework standards.
• Current system maintenance activities with current agency systems – ACTS, HATSS, &
CATS. Improvements, upgrades, or major changes to these systems should be minimized.
Components not within the scope of this project are:

• Automatic or integrated data transfer between ESD systems (Telecenters and/or
Commissioner’s Review Office).
• Billing or time accounting system to replace current OAH systems, e.g., TMS.

Initiation Document
5. ASSUMPTIONS & CONSTRAINTS
Project activities and deliverables are developed with the following assumptions in mind:
• A “test lab” environment will be created and used to mimic the current OAH environment.
The test lab will allow for evaluating technology and for providing a learning “rip-and-tear”
environment. Further “experimentation” will be done in the test lab.
• Technology will be implemented in ‘phases’ (e.g., “Test Lab,” “Pre-Production,” and
“Production”).
• Current existing infrastructure and technology equipment found in field offices (application
servers, Ethernet switches, workstations, etc.) are satisfactory.
• Whenever possible, commercially available solutions (hardware and software) will be used.
• Security and access solutions will be compatible and within established DIS and ISB security
standards.
• Acquisition of services and equipment will be compatible and within established DIS &
OFM purchasing guidelines.
• CMS will be designed around using Microsoft SharePoint 2010 and the suite of Microsoft Office
2010 products (e.g., Outlook, Word, Excel, InfoPath, etc.)
• Project planning will be done using Microsoft Project.
• Integration with current OAH systems will be done using existing OAH IT resources.
• Necessary technology training, if needed, will be made available.
• Staff involved will continue to fulfill their existing duties; however, required resources
(whether existing team members or fill-ins) will be committed to this project as agreed upon
to ensure successful implementation.
• All work will be accomplished within budget allocation as identified in the Supplemental
Budget Request.
The following project activities and deliverables are developed with the following constraints in
mind:
• This project was identified by DIS MOSTD (Management Oversight & Strategic
Technology Direction) as Level 1 project (see appendix A). This required elimination of
automatic & integrated data transfer processes between ESD & OAH.
• Anticipated work load peaks will occur within the agency that will potentially compete for
this project’s resources.
• Operational constraints & agency issues, as well as workload peaks by staff need to be
accommodated (e.g., resource availability).
• Scheduled leave or holidays may limit resource availability at times.
• Project Schedule will identify many tasks that have dependencies which if not met, will cause
a ripple effect downward of the project schedule.
• No alternate resources have been approved should staff become unavailable to perform
their tasks.

Initiation Document
6. RISK FACTORS
It is critical to the success of this project that potential risks be identified and communicated, and a
risk management strategy is in place for each phase of the project. The following table identifies
major risks and mitigation strategies. A separate, more detailed Risk Management Matrix will be
developed and incorporated into OAH’s Risk Registry.
Elements for
Success Risks Leading to Failure Mitigation Strategies
Staff Availability • Key staff may not be • Communicate resources required and gain
available to effectively assurances that staff resources will be made
determine requirements and available in a timely manner.
perform development and
testing.
Manageable • Requirements and • Develop and follow an agreed upon change
Scope requested changes exceed management process.
to scope of the project. • The ‘CMS Steering Committee’ will guide and
keep the project within scope and determine
business requirements.
Planning & • Too aggressive timelines • Use the CMS Steering Committee to guide
coordination • Poorly defined roles & project timelines & milestones
responsibilities • Clearly defined roles & responsibilities
• Poorly defined milestones • Project manager monitors project progress and
coordinate resources
• Track & log issues and events
Knowledge, • Poor CMS design. • Develop a staff training plan.
consulting & • Poor technology (e.g., • Research and investigate agency case
advice SharePoint) knowledge and management techniques and strategies.
understanding. • Coordinate and use existing SharePoint and
• Poor implementation CMS knowledge developed in other state
strategies. agencies.
• Develop and follow a good testing plan.
• Establish good rapport with key business users
and agency experts
• Use the CMS Steering Committee to guide the
project and determine business requirements.
Communication • Poor communication and • Develop and follow an agreed upon change
& coordination coordination with OAH management process.
employees. • Develop and follow a communication plan.
• Poor communication and • Document meeting minutes.
coordination with vendor.
Training • Inadequate technical • Develop and follow a training plan
training • Ensure training made available
• Inadequate staff training • Use IT Liaisons

Initiation Document
7. COST, SCHEDULE, AND RESOURCES
Cost
The total available federal funding awarded by the US DOL for this project is $489,742. The
following table shows a breakdown of the costs by major activity.
Category Cost % Confidence

Equipment (hardware & software) $34,400 90%
CMS Training $20,640 80%
External Consulting & Programming $403,022 80%
Quality Assurance $31,680 70%
TOTAL $489,742
Schedule
The following table provides an overview of major activities and completion dates. A detailed
project schedule will be developed separately to provide additional detail regarding tasks, resources
and dates.

UI CMS Project Initiation October 2010 -
• Identify and document project requirements January 2011
• Identify project governance
• Review other agencies case management systems
• Communication plan
Determine Project Requirements October 2010 -
• Identify hardware & software requirements February 2011
• Identify business requirements through business workgroups
• Map & describe business work flows
• Identify data elements
• Test consolidated business processes
Vendor selection & initial development February 2011 -
• Complete data dictionary & data structures May 2011
• Finalize consolidate business processes
• Complete Software Requirements Specifications (SRS) document
• Complete vendor work order
• Interview & select vendor, contract with vendor
Initial UI CMS review, testing & evaluation June 2011 –
• Prototype & early version (alpha) UI CMS development October 2011
• Testing, evaluation, recommendations, modifications with selected users
• Project Team & UI CMS Steering Committee approval of version changes
• Coordinate changes with vendor and on-going development
• Create test UI CMS environment, ensure hardware & software are operational
• Present pre-production (beta) version to stakeholders

Initiation Document

Final UI CMS testing & preparation for implementation October 2011 –
• Evaluate pre-production UI CMS (beta) and ensure data & functional accuracy December 2011
• Testing, evaluation, modifications, with expanded group of selected users
• Project Team & UI CMS Steering Committee approval of final UI CMS version
• Coordinate changes, modifications, and updates with vendor
• Present UI CMS to ADCs & Office Managers
• Identify training materials and plans
• Create implementation plan
• Create pre-production UI CMS (technical environment) for extensive testing &
functionality
Quality Assurance December 2011 –
• Hire private vendor to perform “light” quality assurance assessment of CMS February 2012
• Prepare for quality assurance - ensure all requirements documentation &
change orders are assembled
• Coordinate with vendor quality assurance
• Review quality assurance report from vendor
UI CMS Implementation March 2012 –
• Perform training at each field office April 2012
• Coordinate with each field office for UI CMS installation
• Provide extra local IT & UI CMS support
• Lessons learned at each local office post-implementation
UI CMS Lessons Learned & Project wrap-up May 2012
• Coordinate with vendor on final UI CMS issues
• Meet with various UI CMS workgroups to do Lessons Learned
• Project Team & Steering Committee approval
• Identify with the vendor and Steering Committee what possible future
improvements can be made for future versions.

Initiation Document
Resources
The following table lists agency resources expected to participate in the project. The “Est. Project
Involvement” column identifies the estimated percent of time the resource is “dedicated” to the
project; since most staff will be participating in the project concurrently with their current job
responsibilities and duties. This percentage estimate is the average for the life-time (estimated 20
months) of the project. Consequently, there may be times when the project resource may
periodically be 100% involved with the project and other times involved very little or not at all.
Est. Project
Resource Project Role
Involvement
Lorraine Lee Project Sponsor, GMAP Project Team 30%
Lead, & CMS Steering Committee
Don Chase Project Manager 50%
Tarisse Injerd Project Coordinator 90%
Bill Dodge Business Project Team Lead 90%
Loree Hawkens Technical Team Lead 50%
Stephanie Croom-Williams Stakeholder Team Lead & CMS Steering 20%
Committee
Virgil Sweeney Time-Keeping BMV Lead & CMS 20%
Steering Committee
Patti Latsch Performance BMV Lead & CMS Steering 20%
Committee
Justin Hansen SharePoint & Technical Team member 50%
John Morgan Technical Team member 30%
Frank Mighetto Technical Team member & multiple 30%
workgroup member
IT Liaisons IT Liaisons 10%
BMV Team Leads BMV Team Leads 15%
BMV & Ad hoc Wrkgrp members BMV & Ad hoc Workgroup members 10%
ADCs ADCs 5%

Initiation Document
8. WORK PRODUCTS
The following work products will be produced.
Major Activity Work Products

CMS Project • Project initiation document
Initiation • Communications plan
• Project schedule
• Risk management plan
• Project team roles and responsibilities document
• Project governance document
Determine Project • Business Activities Document
Requirements • Business work flow drawing
• Data screens indicating elements as determined from business workgroups
• Agency glossary relating to terminology and measures
Vendor Selection & • Data dictionary
Initial Development • Software Requirements Specifications document
• Vendor work request & work order
• Technical flow charts
• Sample or proposed screen views
Initial CMS Review, • Prototype and Alpha CMS releases (for each)
Testing & o Test plan (Implementation, audience, timeline & milestones)
Evaluation o Testing criteria
• Summary of change orders
• Issue & tracking log
Final CMS Testing • Beta CMS release
& Preparation For o Test plan (Implementation, audience, timeline & milestones)
Implementation o Testing criteria
• Summary of change orders, issue & tracking log
• CMS presentation for agency staff and stakeholders
o PowerPoint presentation
o Demonstration of system
• Agency CMS Training plan
• Pre-Implementation plan
Quality Assurance • Vendor work request & work order
• Vendor Quality Assurance report
CMS • CMS documentation – instructions, guides, how-tos, FAQs
Implementation o Policy and procedures relating to use of CMS
• Lessons learned per each local office
• Summary of issue & tracking log
CMS Lessons • Post Implementation Review document (Lessons Learned)
Learned & Project • Vendor summary report
Wrap-Up • Next version recommendations

Initiation Document
9. PROJECT ORGANIZATION
The project governance design can be found in Appendix B.
Not all project positions are defined below, only those that have significant roles and responsibilities
in the project and directly influence the success of the project.
Project Sponsor – Lorraine Lee

The Project Sponsor represents the business processes being addressed by the project and is
ultimately accountable for the project’s success. The Project Sponsor must be committed to change,
must have budget authority over the project, and must be willing to mandate business process
alignment within the program and/or Agency where necessary.
Project Sponsor will:

• Ensure commitment from the organization to participate in the project
manner
• Ensure funding and other resources are available for the duration of the project
• Resolve outstanding project personnel and resource issues
• Supervise and direct the Project Manager, Project Coordinator, and Business Team Lead
Project Steering Committee – Lorraine Lee, Patti Latsch, Stephanie Croom-Williams, Virgil
Sweeney
The Project Steering Committee guides the project and ensures project and business objectives are
being met. The Project Steering Committee must be committed to understanding project
requirements and balance them with business requirements.
Project Steering Committee members will:

manner
• Ensure resources are available for the duration of the project
• Approve project plans
• Approve major project changes (scope, schedule, etc.)
• Approve final reports (deliverables) from all project phases
• Resolve outstanding project operational and functional issues
• Approve recommendations made by the Project Teams

Initiation Document
Project Manager – Don Chase

The Project Manager has the technical managerial oversight of the project and, along with the
Project Sponsor, has overall responsibility for the project. The Project Manager has the basic task of
integrating the efforts of both the user and technical teams in developing the CMS. The Project
Manager assigns the technical project deliverables to specific project personnel and tracks their
progress in accordance with the project plan. The Project Manager is the prime planner, organizer,
and team leader for the project. The Project Manager works very closely with the Project Sponsor
in the development and management of the project from start to finish.
The Project Manager will:

• Plan & control the project
• Direct and coordinate project resources which may include assigning tasks and deliverables
• Approval of project documents, materials, presentations, and status reports
• Provide management oversight of system development tasks
• Be the primary agency contact with the vendor, developers, consultants
• Prepare project work plans & work breakdown structures
• Approve technical system design and specifications, and technical deliverables such as
diagrams and specifications to be used by developers
• Produce project deliverables in accordance with the SDLC project management
methodology
• Verify that design and technical decisions are consistent with the OAH standards and
Project Coordinator – Tarisse Injerd

The Project Coordinator coordinates project meetings, workgroups, training and other
communications are completed timely and within project specifications. The Project Coordinator is
the prime communicator, facilitator, and organizer for the project. The Project Coordinator works
very closely with the Project Manager in the development of the project.
The Project Coordinator will:

• Ensures that the project communications plan is being followed.
• Work with the Project Manager that project milestones, tasks, and events are being met
timely and successfully.
• Coordinates and ensures project resources are available for meetings, tasks, and other project
items.
• Facilitate and lead various meetings (e.g., Steering Committee, training, Lessons Learned,
testing) and workgroup sessions
• Coordinate, facilitate, and/or lead user testing
• Coordinate, facilitate, and/or lead user training
• Coordinate and facilitate CMS implementation
by developers
• Manage & publish content for the SharePoint CMS sites and Inside OAH

Initiation Document
Business Team Lead – Bill Dodge

The Business Team Lead coordinates BMV workgroups, and ad-hoc workgroups for the project and
is the lead ensuring that business elements are included in the CMS. The Business Team Lead works
very closely with the Project Manager and Project Coordinator in the development of the project.
The Business Team Lead will:

• Ensure that the communications plan is being followed.
• Coordinate and ensure project resources are available for meetings, tasks, and other project
items.
• Assist in facilitation & organization of BMV Workgroup & Ad hoc workgroups, user testing
and user training meetings
• Assist in user testing
• Assist in user training
• Assist in CMS implementation
by developers
• Assist in managing & publishing content for the SharePoint CMS sites – Steering Committee
& Workgroups.
• Verify that CMS design and deliverables are consistent with the OAH legal standards and
Technical Lead – Loree Hawkens

The Technical Lead provides the linkage between the technical needs of the project and business
requirements. The Technical Lead is the technical subject matter expert who understands the
detailed business aspects of the project and will provide a clear understanding as to what
functionality the system must provide to the potential system users. The Technical Lead is expected
to work very closely with the Project Manager and Project Sponsor, and interfaces continually with
others working on the project.
Technical Network Lead will:

• Provide technical oversight on the CMS technical system
• Define the basic concepts of the system to meet needed functionality
• Determine information and system requirements
• Perform and assign technical tasks, as needed
• Prepare test plans and test data, and coordinate and conduct system testing
• Define and document operational procedures

Initiation Document
10. SUCCESS MEASURES
The following factors will be used to guide and measure the success of this project.
• Project concludes with all identified work plan components (tasks and milestones)
successfully completed within the scheduled time and budget.
• All project purchases (hardware, software, consulting, development, and training) are
completed by 09/30/12.
• Good system performance;
o Measures:
No. of help desk calls;
Server & database system uptime of greater than 99.9%; and,
• Good coordination between OAH and DIS.
o Measures:
Written evaluation written by DIS MOSTD;
• Good coordination between OAH and ESD.
o Measures:
Written evaluation written by ESD and ESD Commissioners Review Office;
• Good coordination between OAH and vendors;
o Measures:
Closing vendor evaluation;
• Good coordination between CMS Project Team and OAH employees/customers;
o Measures:
Closing survey & evaluation with a cumulative score above 3.3 (1 poor – 5
excellent) in the following categories:
Testing;
Training;
Communication methods; and,
Implementation.
• The CMS system receives a cumulative approval rating by OAH staff equal to or greater
than 3.3 (1 poor – 5 excellent) in the following areas:
o Functionality; and,
o Design, layout & appearance.
• CMS project plan milestones met within 90% of the time as set forth in the project plan.

Initiation Document
11. AGREEMENT
The following signatures by the Project Sponsor and Project Manager indicate acceptance and
approval of the Project Initiation document as written.
Lorraine Lee, Chief Administrative Law Don Chase, CIO & Project Manager
Judge

Initiation Document
Appendix A. – MOSTD Oversight Severity & Risk Analysis
Severity Level Criteria

The severity matrix assesses the proposed project’s impact on citizens and state operations, its visibility
to stakeholders, and the consequences of project failure.
Categories
Impact on Visibility Impact on State Failure or Nil

Levels Clients Operations Consequences
High • Direct contact • Highly visible to • Statewide or • Inability to meet

with citizens, public, trading multiple agency legislative mandate
political partners, political involvement / or agency mission.
subdivisions, and subdivisions and impact. • Loss of significant
service providers Legislature. • Initial mainframe federal funding.
– including • Likely subject to acquisitions or
benefits hearings. network
payments and • System acquisitions.
transactions. processes
sensitive /
confidential data
(e.g. medical,
SSN, credit card
#’s).
• Indirect impacts • Some visibility to • Multiple • Potential failure of
Medium on citizens the Legislature, divisions or aging systems.
through trading partners, programs
management or public the within agency.
systems that system / program
support supports.
decisions that • May be subject to
are viewed as legislative hearing.
important by the
public.
• Access by
citizens for
information &
research
purposes.
• Agency • Internal agency • Single division. • Loss of opportunity
Low operations only. only. • Improve or for improved
expand existing service delivery or
networks or efficiency.
mainframes with • Failure to resolve
similar customer service
technology. complaints or
requests.

Initiation Document
Risk Level Criteria

The risk matrix measures the impact of the project on the organization, the effort needed to complete the
project, the stability of the proposed technology, and agency preparedness.
Categories
Functional Impact Development Effort Technology Capability &

on Business & Resources Management
Processes or
Levels Rules
• Significant change • Over $5 million. • Emerging. • Minimal executive
High to business rules. • Development and • Unproven. sponsorship.
• Replacement of a implementation • Two or more of the following • Agency uses ad-hoc
mission critical exceeds 24 months.* are new for agency technology processes.
system. • Requires a second staff or integrator, or are new to • Agency and/or vendor
• Multiple decision package. the agency architecture: track record suggests
organizations programming language; inability to mitigate
involved. operating systems; database risk on project
• Requires extensive * Clock starts after products; development tools; requiring a given level
and substantial job feasibility study or data communications of development effort.
training for work project approval and technology.
groups. release of funding. • Requires PKI certificate.
• Complex architecture – greater
than 2 tier.
• Moderate change to • Under $5 million • New in agency with 3rd party • Executive sponsor
Medium business rules. but over agency expertise and knowledge knowledgeable but
• Major enhancement delegated transfer. not actively engaged.
or moderate change authority. • One of the technologies listed • System integrator
of mission critical • 12 to 24 months for above is new for agency under contract with
system. development and development staff. agency technical
• Medium complexity implementation. * participation.
business • Agency and/or vendor
process(es). * Clock starts after record indicates good
• Requires moderate feasibility study or level of success but
job training. project approval and without the structure
release of funding. for repeatability.
• Insignificant or no • Within agency • Standard, proven agency • Strong executive

Low change to delegated authority. technology. sponsorship.
business rules. • Under 12 months • Agency and vendor
• Low complexity for development have strong ability to
business and mitigate risk on a
process(es). implementation.* development project.
• Some job training • Project staff uses
could be required. documented and
* Clock starts after repeatable processes
feasibility study or for tracking status,
project approval and problems, and
release of funding. change.
• Agency or vendor is
CMM Level 3
equivalent or above.

Initiation Document
Project Approval and Oversight Matrix

The level of approval and oversight required on a given project is determined through an assessment of
project risk and severity:
Level Level Level

High Severity
2 2 3
Level Level Level
Medium Severity
1 2 2
Level Level Level
Low Severity
1 1 1
Low Risk Medium Risk High Risk

Initiation Document

CMS Initiation Final

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CMS Initiation Final

Загружено:

Авторское право:

Доступные форматы

New Case Management

System (CMS) Project

January 27, 2011

Date Version Editor Changes

1. Project Statement ..................................................................................................................................... 1

2. Business Case ........................................................................................................................................... 1

6. Risk Factors .............................................................................................................................................. 5

7. Cost, Schedule, and Resources .............................................................................................................. 6

8. Work Products ......................................................................................................................................... 9

9. Project Organization ............................................................................................................................. 10

10. Success Measures ................................................................................................................................... 13

Appendix A. MOSTD Oversight Severity & Risk Analysis ...................................................................... 15

Appendix B. New UI CMS Governance ...................................................................................................... 18

January 27, 2011 Version 1.2 Page 1

At the completion of this project, we will have a system that:

January 27, 2011 Version 1.2 Page 2

All of OAH will be affected by this project.

Components within the scope of this project are:

Components not within the scope of this project are:

January 27, 2011 Version 1.2 Page 3

5. ASSUMPTIONS & CONSTRAINTS

January 27, 2011 Version 1.2 Page 4

January 27, 2011 Version 1.2 Page 5

7. COST, SCHEDULE, AND RESOURCES

Category Cost % Confidence

Major Activities and Tasks Dates

January 27, 2011 Version 1.2 Page 6

Major Activities and Tasks Dates

January 27, 2011 Version 1.2 Page 7

January 27, 2011 Version 1.2 Page 8

The following work products will be produced.

Major Activity Work Products

January 27, 2011 Version 1.2 Page 9

The project governance design can be found in Appendix B.

Project Sponsor – Lorraine Lee

Project Sponsor will:

Project Steering Committee members will:

January 27, 2011 Version 1.2 Page 10

Project Manager – Don Chase

The Project Manager will:

Project Coordinator – Tarisse Injerd

The Project Coordinator will:

January 27, 2011 Version 1.2 Page 11

Business Team Lead – Bill Dodge

The Business Team Lead will:

Technical Lead – Loree Hawkens

Technical Network Lead will:

January 27, 2011 Version 1.2 Page 12

10. SUCCESS MEASURES

January 27, 2011 Version 1.2 Page 13

January 27, 2011 Version 1.2 Page 14

Appendix A. – MOSTD Oversight Severity & Risk Analysis

Severity Level Criteria

Impact on Visibility Impact on State Failure or Nil

High • Direct contact • Highly visible to • Statewide or • Inability to meet

January 27, 2011 Version 1.2 Page 15

Risk Level Criteria

Functional Impact Development Effort Technology Capability &

• Insignificant or no • Within agency • Standard, proven agency • Strong executive

January 27, 2011 Version 1.2 Page 16

Project Approval and Oversight Matrix

Level Level Level

January 27, 2011 Version 1.2 Page 17

January 27, 2011 Version 1.2 Page 18