[INSERT PROJECT NAME] · Web viewAgile PM also emphasizes team work. Managers, customers, end users, and developers are all part of a team dedicated to delivering quality products

JUDICIAL CASE MANAGEMENT APPLICATION

PROJECT MANAGEMENT PLAN

Executive Sponsor – JIFFYBusiness Owner – Arthur Pipen

Project Manager – Tom EdwardsOriginal Plan Date: MMAYAY 1, 2007 1, 2007

Revision Date: MMAYAY 31, 2007 31, 2007Revision: N/AN/A

Judicial Case Management Application Project Management Plan

TABLETABLE OFOF CONTENTSCONTENTS

Revision HistoryRevision History........................................................................................................................................................vivi1.01.0 Project OverviewProject Overview......................................................................................................................................11

1.11.1 IINTRODUCTIONNTRODUCTION..................................................................................................................................................................111.21.2 CCURRENTURRENT S STATETATE..............................................................................................................................................................111.31.3 FFUTUREUTURE S STATETATE..................................................................................................................................................................221.41.4 NNEEDEED....................................................................................................................................................................................................22

2.0 Scope2.0 Scope..................................................................................................................................................................................332.1 P2.1 PROJECTROJECT J JUSTIFICATIONUSTIFICATION..........................................................................................................................................332.2 P2.2 PROJECTROJECT O OBJECTIVESBJECTIVES....................................................................................................................................................55

2.2.1 BUSINESS OBJECTIVES......................................................................................52.2.2 TECHNICAL OBJECTIVES...................................................................................6

2.3 D2.3 DELIVERABLESELIVERABLES............................................................................................................................................................................662.3.1 PROJECT MANAGEMENT DELIVERABLES........................................................6

2.3.1.1 PROJECT MANAGEMENT PLAN....................................................................62.3.1.2 [DELIVERABLE 2 NAME]..............................................................................7

2.3.2 PRODUCT DELIVERABLES.................................................................................72.3.2.1 [DELIVERABLE 1 NAME]..............................................................................72.3.2.2 [DELIVERABLE 2 NAME]..............................................................................7

2.3.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS..................................82.3.4 DELIVERABLE ACCEPTANCE PROCEDURE.......................................................8

2.4 W2.4 WORKORK B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE (WBS) (WBS)......................................................................................883.0 Overall Strategy3.0 Overall Strategy..............................................................................................................................................99

3.1 P3.1 PROJECTROJECT M MANAGEMENTANAGEMENT L LIFEIFE C CYCLEYCLE................................................................................................993.2 C3.2 CRITICALRITICAL S SUCCESSUCCESS F FACTORSACTORS............................................................................................................................993.3 P3.3 PROJECTROJECT L LOGISTICSOGISTICS......................................................................................................................................................10103.4 P3.4 PRODUCTRODUCT L LIFEIFE C CYCLEYCLE M MODELODEL..................................................................................................................10103.5 T3.5 TECHNICALECHNICAL S STRATEGYTRATEGY............................................................................................................................................1010

4.0 Project Organization4.0 Project Organization..........................................................................................................................10104.1 S4.1 STAKEHOLDERSTAKEHOLDERS....................................................................................................................................................................10104.2 C4.2 CUSTOMERSUSTOMERS..................................................................................................................................................................................11114.3 P4.3 PROJECTROJECT T TEAMEAM......................................................................................................................................................................1111

4.3.1 PROJECT TEAM ORGANIZATIONAL BREAKDOWN STRUCTURE....................124.3.2 PROJECT TEAM ROLES AND RESPONSIBILITIES............................................13TEAM MEMBERS (SECONDARY AND EXTENDED TEAM MEMBERS).......................13

5.0 Project Management and Controls5.0 Project Management and Controls............................................................................13135.1 S5.1 STAFFINGTAFFING P PLANNINGLANNING ANDAND A ACQUISITIONCQUISITION......................................................................................13135.2 A5.2 ASSUMPTIONSSSUMPTIONS............................................................................................................................................................................14145.3 C5.3 CONSTRAINTSONSTRAINTS............................................................................................................................................................................1414

5/20/2023 i


5.4 D5.4 DEPENDENCIESEPENDENCIES........................................................................................................................................................................14145.4.1 MANDATORY DEPENDENCIES.........................................................................155.4.2 DISCRETIONARY DEPENDENCIES....................................................................155.4.3 EXTERNAL DEPENDENCIES.............................................................................15

5.5 R5.5 RISKISK M MANAGEMENTANAGEMENT......................................................................................................................................................15155.5.1 RISK MANAGEMENT STRATEGY.....................................................................155.5.2 PROJECT RISK IDENTIFICATION.....................................................................155.5.3 PROJECT RISK ANALYSIS................................................................................17

5.5.3.1 [RISK 1 NAME]...........................................................................................17PROBABILITY AND IMPACT -....................................................................................17

5.5.3.2 [RISK 2 NAME]...........................................................................................17PROBABILITY AND IMPACT -....................................................................................175.5.4 PROJECT RISK MITIGATION APPROACH.......................................................175.5.5 RISK REPORTING AND ESCALATION STRATEGY...........................................185.5.6 PROJECT RISK TRACKING APPROACH...........................................................18

5.6 I5.6 INDEPENDENTNDEPENDENT V VERIFICATIONERIFICATION ANDAND V VALIDATIONALIDATION - IV&V - IV&V................................18185.7 S5.7 SCOPECOPE M MANAGEMENTANAGEMENT P PLANLAN............................................................................................................................19195.8 I5.8 ISSUESSUE M MANAGEMENTANAGEMENT....................................................................................................................................................2020

5.8.1 INTERNAL ISSUE ESCALATION AND RESOLUTION PROCESS.........................205.8.2 EXTERNAL ISSUE ESCALATION AND RESOLUTION PROCESS........................20

5.9 P5.9 PROCUREMENTROCUREMENT M MANAGEMENTANAGEMENT P PLANLAN..............................................................................................21215.10 C5.10 CHANGEHANGE C CONTROLONTROL......................................................................................................................................................2121

5.10.1 CHANGE CONTROL PROCESS........................................................................215.10.2 CHANGE CONTROL BOARD (CCB)...............................................................22

5.11 P5.11 PROJECTROJECT T TIMELINEIMELINE....................................................................................................................................................23235.12 P5.12 PROJECTROJECT B BUDGETUDGET..........................................................................................................................................................2424

5.12.1 BUDGET TRACKING.......................................................................................245.13 C5.13 COMMUNICATIONOMMUNICATION P PLANLAN......................................................................................................................................2424

5.13.1 COMMUNICATION MATRIX...........................................................................265.13.2 STATUS MEETINGS........................................................................................275.13.3 PROJECT STATUS REPORTS..........................................................................27

5.14 P5.14 PERFORMANCEERFORMANCE M MEASUREMENTEASUREMENT (P (PROJECTROJECT M METRICSETRICS))......................................27275.14.1 BASELINES......................................................................................................275.14.2 METRICS LIBRARY........................................................................................27

5.15 Q5.15 QUALITYUALITY O OBJECTIVESBJECTIVES ANDAND C CONTROLONTROL........................................................................................27275.15.1 CUSTOMER SATISFACTION............................................................................285.15.2 DELIVERABLE DEFINITION............................................................................285.15.3 DELIVERABLE QUALITY................................................................................285.15.4 PROJECT/PRODUCT DELIVERABLE PRESENTATION....................................29

5.16 C5.16 CONFIGURATIONONFIGURATION M MANAGEMENTANAGEMENT..........................................................................................................29295.16.1 VERSION CONTROL.......................................................................................295.16.2 PROJECT REPOSITORY (PROJECT LIBRARY)...............................................29

6.0 Project Close6.0 Project Close......................................................................................................................................................29296.1 A6.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE........................................................................................................................................3030

5/20/2023 ii


6.2 C6.2 CONTRACTONTRACT C CLOSELOSE............................................................................................................................................................30307.0 Glossary7.0 Glossary....................................................................................................................................................................3030

7.1 A7.1 ACRONYMSCRONYMS ANDAND A ABBREVIATIONSBBREVIATIONS............................................................................................................30307.2 D7.2 DEFINITIONSEFINITIONS................................................................................................................................................................................3030

5/20/2023 iii


LLISTIST OFOF F FIGURESIGURES

Project Management Life Cycle………………………………………………………….8Stakeholders………………………………………………………………………………9Project Team…………………………………………………………………………….10Project Organization Chart………………………………………………………………11Initial Risks………………………………………………………………………………15Communications Matrix…………………………………………………………………21

5/20/2023 iv


LLISTIST OFOF A APPENDICESPPENDICES

Appendix A: Work Breakdown Structure

Appendix B: Project Schedule

Appendix C: Project Forms

5/20/2023 v


RREVISIONEVISION H HISTORYISTORY

Revision Number Date Comment1.0 May 1, 2007 Initial Plan1.1 June 7, 2007 Revisions/updates from OCIO meeting

5/20/2023 vi

Judiciary Case Management Application Project Management Plan

1.01.0 PPROJECTROJECT O OVERVIEWVERVIEW

1.11.1 IINTRODUCTIONNTRODUCTIONThe Judicial Information Division (JID) maintains one of the few consolidated statewide court case tracking systems in the United States for multiple court districts. This allows the judiciary to provide up-to-date offender information to judges throughout the system. This information is essential to the justice process since knowledge of warrants, protective orders and past offenses enhances a judge’s ability to deliver appropriate bonding and sentencing decisions. Executive-branch justice agencies also use judicial information to assist in making accurate charging decisions and appropriate correctional facility placement determinations. As such, a case management system is integral to an effective justice process and to the overall impact justice has on the citizens of New Mexico.

1.21.2 CCURRENTURRENT S STATETATE

The Judiciary’s core business functions include processing and managing approximately 367,000 case filings annually and collecting substantial amounts of fines and fees associated with case filings. Other case management functions include scheduling court events, recording all court activities, reporting dispositions and sentencing, and much more. In addition, the case management system must accommodate system modifications in response to legislatively mandated changes.

The current application does not adequately support all business needs of the courts. Court staff are often frustrated with the quantity of pull-down and pop-up menus relating to numerous unusable options. In addition, numerous error corrections must be made and these errors usually could have been prevented by built-in data edits. Even when data are essentially correct, the lack of workflow and business process standards can make reporting difficult.

The application’s decentralized client-server design makes it difficult for New Mexico’s remote court locations that are forced to rely on low bandwidth telecommunications to process transactions in a timely and efficient manner. Over the past two years, JID has endeavored to improve response time, the accuracy and availability of data through vendor-supplied upgrades and communications enhancements. However, some of the “improvements” to the application have caused bigger problems, such as system locking and slower response times, than the ones they resolved.

Over the past two years, the vendor has shown preference for supporting its law enforcement systems instead of its courts application. This puts the Judiciary in the untenable position of not having adequate support for its primary software applications. In Compudyne Law and Justice’s 2005 annual report, the “Key products and services in the Public Safety and Justice” section no longer lists court systems. Additionally, none of their press releases or sponsored key events for the past two years have involved court systems or court clients. From this, it is

5/20/2023 1


apparent that this vendor’s business strategy is to move away from its aging judicial products to focus exclusively on law enforcement, dispatch, and physical security products.

Since Compudyne Law and Justice is obviously not able or willing to support the New Mexico’s judicial computer applications evolving needs, obtaining a new case management system is urgent and imperative.

1.31.3 FFUTUREUTURE S STATETATEThe future state is best described through a set of judiciary requirements, as described below:

The New Mexico Judiciary requires an improved method of maintaining judicial calendars so that scheduling data can be electronically shared with other state and local law enforcement agencies. The New Mexico Judiciary requires an updated Case Management System that is designed to integrate/operate effectively in an internet environment. A new Case Management System must perform adequately despite limited telecommunications capabilities in New Mexico.

A Case Management System must easily consolidate court case data statewide into a data repository for simplified statewide reporting.

A future system will be required to perform data validation and quality checks. The Administrative Office of the Courts is mandating that business logic specific to New

Mexico be built into a future application to prevent data entry errors. The New Mexico Judiciary demands a system where JID staff can easily customize data

entry screens to match documents filed so that data entry is streamlined.

1.41.4 NNEEDEEDThe work of the courts is inevitably information-intensive. The New Mexico Judiciary's case management application was purchased more than ten years ago and has been operational since 1997. Although justifications for a new case management system will be explained in greater detail in the Project Justification section below, the following list summarizes issues surrounding the need for replacement of the Judiciary's case management application:

The current application is more than ten years old and is based on cumbersome two-tier client-server technologies.

Court users are required by the application to navigate through multiple screens to process simple transactions that should be enabled by one screen.

There are few if any built-in application edits to assist courts in data entry integrity. The application design (decentralized and client server based instead of web based) uses

Wide Area Network (WAN) resources inefficiently. Last but certainly not least, the current application's vendor, Compudyne Law and

Justice, has all but abandoned support for its court case management applications. This means that the Judiciary is completely without vendor support in the event of a catastrophic failure.

In summary, maintaining the current system is untenable. The application is not supported and there’s no realistic possibility that the system can be upgraded to meet the Judiciary's current or

5/20/2023 2


future business needs. Therefore, it is critical that a replacement system be obtained before an event occurs from which the Judiciary would have great difficulty recovering.

2.0 S2.0 SCOPECOPE The project scope for the Case Management System states what will and will not be included as part of the project. Scope provides a common understanding of the project for all stakeholders by defining the project's overall boundaries. Once the Project Charter is accepted, changes to scope will require invocation of the Change Management strategy.

The Case Management System scope will include at least the same functionality as currently provided by the FACTS system. In addition, there will be new features to enhance productivity, decrease data entry errors, and improve financial accounting.

The Case Management System will support all state courts in New Mexico; District Courts, Magistrate Courts, and Metro Court. Although the intent is to have the Municipal Courts able to use the new system, any requirements fully unique to the Municipal Courts are not included in the scope of this project. Those requirements can be added later as an enhancement to the system.

ScopeWithin ScopeAll functional capabilities currently in FACTS 5.XFull bond tracking, accounting, and reportingFull financial and audit functionality Case initiation and all case eventsAll District CourtsAll Magistrate CourtsMetro CourtOutside ScopeMunicipal Courts

2.1 P2.1 PROJECTROJECT J JUSTIFICATIONUSTIFICATIONThe nationally recognized life cycle for an application is up to 10 years. The New Mexico Judiciary’s application is almost 15 years old and the vendor has not made the necessary improvements so that the application can operate effectively in today’s information technology environment. This ineffective operation costs the Judiciary in staff time due to increased wait time for processes to complete because it is not web based nor does it operate well on a slow telecommunications line.

Quantitative Benefits: Based on field estimates, implementing an effective court-calendaring module could save at least two hours per week for each operating courtroom. These benefits would be derived from court staff not having to manually collect, consolidate, and report a

5/20/2023 3


judicial dockets and schedules. With more than 250 judges in New Mexico, this could be a staff productivity gain of 26,000 hours per year. As workloads in the courts continue to increase these productivity gains could reduce work backlogs and allow court staff to better serve the public.

A calendaring module could also more effectively communicate hearing dates and times to lawyers, the general public and other justice entities (private attorneys, law enforcement, district attorneys and public defenders). This has the potential to lower dismissal rates resulting from law enforcement officers failing to appear for court, and may even reduce officer overtime by providing law enforcement and justice officials with the ability to better schedule their time around court dates.

At present, court clerks are required to enter much of the same data on separate screens during case initiations, dispositions, and other event transactions. In several off-the-shelf applications, once the data is entered on the initial screen, a workflow manager function can transfer the same data to other screens or derive needed data from the application, thereby significantly reducing keystrokes and error corrections.

In addition, the existing system has few data entry fields that incorporate field edits to ensure correct data. Most current off-the-shelf applications allow for defined field edits to be incorporated into the user interface. These field edits should prevent users from entering incorrect information and also allow for pre-defined entries to be selected from pull-down lists (e.g. city, state, zip code, dates, etc.). This will substantially improve data integrity and reduce time now spent on data corrections.

These features of workflow functions, data derivations and front-end edits could save each data entry user significant data entry time. If these savings were only ten minutes per person, per day, this would result in total staff productivity gains of up to 25,000 hours per year.

Much of JID’s application support staff workload is focused on testing patches and maintenance releases, and on training end-users in how to make effective use of the case management system. Transactional data entry now requires data entry clerks to jump between screens and search for codes using built-in screen links that have little or no logic. A new system would provide a more intuitive user interface, which will allow JID application support staff productivity gains of up to 20% and reduce on-going testing and training time (for both trainer and trainee) by 25% to 40%. This should reduce travel and lodging costs by more than $30,000 per year and provide application support staff with time to spend on court improvement IT projects.

Qualitative Benefits: The current system was designed prior to present-day expectations of increased individual privacy and confidentiality. Several off-the-shelf applications now ensure that built-in security functions will provide the following benefits:

Faster, more secure and more reliable access to court dispositions and scheduling data for New Mexico residents and other New Mexico justice entities

5/20/2023 4


Improved confidence in the integrity and confidentiality of information stored in the system

Enhanced security for cases that have been sealed or expunged Role-based security to ensure that only those who need access to sensitive information,

such as personal identifiers and social security numbers, will be able to see such information

Improved authentication and identification to prevent unneeded and unauthorized access to information

Overall the qualitative benefits offered by most available off-the-shelf applications will increase the speed and accuracy of information supplied to New Mexico citizens and provide enhanced functionality that will improve access to information required by prosecutors, probation officers, parole officers, law enforcement personnel and judges.

Assuming investment estimate of $7.1 million (submitted as FY08 request), the annual value of improved service to citizens is $2,013:

Pay Back Period 3.5 years Return on Investment-ROI (at 6% discount rate) 117.2%

2.2 P2.2 PROJECTROJECT O OBJECTIVESBJECTIVESA new Case Management System will integrate traffic, civil, and criminal case management information, enabling communication and data sharing between all state courts and other justice related entities. The new system is expected to increase productivity and efficiency by giving judges and court staff more accurate and timely access to files.

In addition, the new system is expected to increase access to court information by lawyers, citizens, and other participants in the judicial process. The new system is expected to provide infrastructure that will allow later development of electronic filing systems, which will enable litigants and their legal counsel to file documents electronically; this will eventually alleviate existing severe burdens imposed by paper storage requirements. The initial business and technical objectives of the project include the following:

2.2.1 B2.2.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES

NNUMBERUMBER DDESCRIPTIONESCRIPTION

Bus. Objective 1 Improve case management system response time in remote (56k/dialup) areas by 25%

Bus. Objective 2 Reduce Case Management server, storage, and backup administration time by 25%

Bus. Objective 3 Increase usage of calendaring function to 75% of state courtsBus. Objective 4 Reduce current case management system data entry errors by 50%Bus. Objective 5 Standardize business rules/workflow processes to improve data entry

productivity by 10%Bus. Objective 6 Reduce losses by 75% resulting from incorrect or multiple payment/re-

5/20/2023 5



imbursement of bondsBus. Objective 7 Ensure inter-agency (state and national) data exchange by creating data

elements that comply with national GJXDM/NIEM data sharing standards

Bus. Objective 8 Reduce in-class training time and travel costs by 50%

2.2.2 T2.2.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


Tech. Objective 1 Provide 99.9% Case Management System availability during published court office hours

Tech. Objective 2 Browser based application, incorporating n-tier application architecture designed with Open Standards using Best Practices. Utilize Open Source components where feasible.

Tech. Objective 3 User authentication and role-based authorization supported by an LDAP service.

Tech. Objective 4 Utilize a database which incorporates Open Standards and Open Source where feasible.

Tech. Objective 5 CMS runs on the current judiciary operating system.Tech. Objective 6 The CMS supports IP and si capable of providing QoS (quality of

service) over the lowest network bandwidth available to court users in the state.

2.3 D2.3 DELIVERABLESELIVERABLESMany of the project and product deliverables are subject to the features and methodology of the selected vendor. This section will be completed once the vendor is selected through the RFP process. However, the methodology the AOC uses for defining, processing and accepting deliverables is consistent for any project and the process is described and defined starting on page 50 of this document.

2.3.1 P2.3.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

Although the specifics of some deliverables are dependent on the product and vendor selected, the initial project management plan and a few other documents can be identified and listed.

2.3.1.1 PROJECT MANAGEMENT PLAN

Description – Project Management Plan

Deliverable Acceptance Criteria – ITC Certification

Standards for Content and Format – Conform to PMI standardsQuality Review – Project manager, AOC, and JIFFY

5/20/2023 6


2.3.1.2 DATA MIGRATION AND CONVERSION PLAN

Description – Data migration and conversion plan

Deliverable Acceptance Criteria – See deliverable acceptance criteria on page 51 of this documentStandards for Content and Format – Conform to process and procedures for deliverables starting on page 50 of this documentQuality Review - Project manager, AOC, and JIFFY

2.3.1.3 TRAINING PLAN

Description – Training plan and rollout schedule

Deliverable Acceptance Criteria – See deliverable acceptance criteria on page 51 of this documentStandards for Content and Format – Conform to process and procedures for deliverables starting on page 50 of this documentQuality Review - Project manager, AOC, and JIFFY

2.3.2 P2.3.2 PRODUCTRODUCT D DELIVERABLESELIVERABLES

Although the specifics of some deliverables are dependent on the product and vendor selected, the initial product deliverables can be identified and are listed below. This section will be completed once the vendor is selected through the RFP process.

2.3.2.1 HARDWARE INSTALLATION

Description – Installed hardware in vendor recommended configuration

Deliverable Acceptance Criteria - See deliverable acceptance criteria on page 51 of this documentStandards for Content and Format - Conform to process and procedures for deliverables starting on page 50 of this documentQuality Review - Project manager, AOC, and JIFFY

2.3.2.2 APPLICATION INSTALLATION

Description – Installed application software in vendor recommended configuration


5/20/2023 7


2.3.2.3 DATABASE INSTALLATION

Description – Installed database software in vendor recommended configuration


2.3.2.4 SYSTEM CONFIGURATION

Description – Configure control and code tables for application and database software for specifics of New Mexico courts


2.3.3 D2.3.3 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

DDATEATE AAPPROVEDPPROVED

2.3.1.1 Project Management Plan (PMP) JIFFY and ITC TBD2.3.1.2 Data migration and conversion plan PM and BA Manager TBD2.3.1.3 Training plan PM and BA Manager TBD2.3.1.4 TBD TBD TBD2.3.2.1 Hardware installation PM and Sys Manager TBD2.3.2.2 Application installation PM and BA Manager TBD2.3.2.3 Database installation PM and Sys Manager TBD2.3.2.4 System configuration PM, Sys, and BA

ManagersTBD

2.3.2.5 TBD TBD TBD

2.3.4 D2.3.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Deliverables will be reviewed by the appropriate project team members and accepted by signatures of the project manager and the project owner on a Deliverable Acceptance Form in Appendix C.

2.4 W2.4 WORKORK B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE (WBS) (WBS)Once a vendor is selected, details of the WBS/WBS dictionary will be expanded as the project progresses and team assignments are made. The high-level WBS is included in Appendix B. Once a product and vendor is selected through the RFP process, the WBS will be expanded to its final level and a WBS dictionary will also be created.

5/20/2023 8


3.0 O3.0 OVERALLVERALL S STRATEGYTRATEGYThe overall strategy is to use tools and techniques that can produce the best product in the shortest period at the least cost. To do this, JID will use a methodology that is mature in the industry, but new to some JID staff and to the state. Although new, it is centered around practices that project managers have been using for years. According to Jim Highsmith, an author and proponent of Agile Project Management, there are four dimensions along which one can improve any software project. You need to improve communication. You need to seek simplicity. You need to get feedback on how well you are doing. And you need to always proceed with courage.

Agile PM is successful because it stresses customer satisfaction. The methodology is designed to deliver the product your customer needs when it is needed. Agile PM empowers project staff to confidently respond to changing customer requirements, even late in the life cycle. Agile PM also emphasizes team work. Managers, customers, end users, and developers are all part of a team dedicated to delivering quality products.

3.1 P3.1 PROJECTROJECT M MANAGEMENTANAGEMENT L LIFEIFE C CYCLEYCLEThe AOC will use the traditional PMI life cycle model depicted in the graphic below, coupled with the Agile Project Management techniques by Highsmith.

http://www.netways.com/project_management.shtml

3.2 C3.2 CRITICALRITICAL S SUCCESSUCCESS F FACTORSACTORS

Success is defined by how well the tools are used by the Judges and staff of the courts to improve the efficiency and effectiveness of adjudicating cases and performing court business on behalf of the citizens of the State of New Mexico. Some of the initial, high level, critical success factors that demonstrate achievement include:

executive management support and sponsorship of the project availability of appropriate internal and external resources throughout the project adherence to the project management methodology and plans established in the PMP

5/20/2023 9


Specific and measurable critical success factors will be developed once the vendor is selected through the RFP process.

3.3 P3.3 PROJECTROJECT L LOGISTICSOGISTICSAs much work as possible will be done at the physical location of the assigned resources. However, the selection/evaluation team will be required to meet regularly at a site convenient to all members. Customization supported by vendors will physically reside at JID. JID will provide work areas, equipment, and access to communications necessary for a productive work environment, including access to remote vendor networks.

3.4 P3.4 PRODUCTRODUCT L LIFEIFE C CYCLEYCLE M MODELODEL

Since each vendor’s product may be positioned differently in the product life cycle, this section will be developed once the RFP process is completed and a vendor selected.

3.5 T3.5 TECHNICALECHNICAL S STRATEGYTRATEGY

The technical strategy primarily is dependent on the vendor and products selected in the RFP process (e.g. backend database the product uses). However, there are a few key components of the technical strategy and architecture that must be maintained which include, but are not limited to the following:

Any proposed case management application must be “centrally administered” and maintainable by AOC staff without onsite or online remote vendor support.

The application architecture must be browser based or true client server, with preferably 3 or more separate tiers.

The application should function within the physical constraints of the New Mexico Judiciary’s network environment. It should provide an application response time of 3 seconds or less for common transactions.

4.0 P4.0 PROJECTROJECT O ORGANIZATIONRGANIZATIONThe project will be organized in a traditional matrix organization structure. Staff assigned to the project will report to a team leader or for project tasks, but will report to their traditional manager for administrative processes such as performance appraisals, long-term training, etc. Priority conflicts will be negotiated between the functional and technical managers. Typically, the needs of the project will take precedence, but if a consensus cannot be reached, the issue will be referred to the JID CIO for resolution.

4.1 S4.1 STAKEHOLDERSTAKEHOLDERSAn effective case management system allows the judiciary to provide up-to-date offender information to judges throughout the system. This information is essential to the justice process since knowledge of warrants, protective orders and past offenses enhances a judge’s ability to deliver appropriate bonding and sentencing decisions. Executive-branch justice agencies also use judicial information to assist in making accurate charging decisions and appropriate correctional facility placement determinations. Therefore, all resources associated with

5/20/2023 10


Judiciary case related information will have an interest in the project. The key stakeholders are:

Stakeholder Interest in ProjectJudges Enterprise case information for sentencingCourt Administrators Access to and analysis of case dataCourt Staff Ease of data entry/access to system informationProbation and Parole Data currency and integritySentencing Commission Trend and historical analysis Executive Justice Agencies Data exchangeProject Team Members Successful implementation of the project

4.2 C4.2 CUSTOMERSUSTOMERSClerksTrial Court Administrative AssistantsJudgesHearing OfficersCourt AdministratorsFinancial PersonnelAdministrative Office of the CourtsJudicial Information Division StaffCourt IT staffExecutive Branch Justice Related Agencies Public

4.3 P4.3 PROJECTROJECT T TEAMEAMThe nature and impact of replacing and fully consolidating all Case Management Systems requires that a formal Steering Committee to lead the decision making to ensure all state courts (Supreme, Appellate, District, Magistrate, Metro, etc.) interests are heard and needs are addressed. The chart below displays the team assignments for the project.

This project will operate under a matrix organization structure for all internal participants. The table below identifies probable members of the Steering Committee, Primary and Extended team members, and Advisory participants.

Project Role Name Location Interest in ProjectSteering Committee

(possible members)Judge BustamanteSteve PrisocJudge MitchellKaren JanesOscar ArevaloJudge NakamuraTBDLinda Short

AlbuquerqueSanta FeRoySanta FeSanta FeAlbuquerqueTBDPortales

JIFFY Chair/Appellate Courts JID CIOMagistrate JudgeMagistrate Div AdminAOC CFOMetro JudgeDistrict JudgeCMAUG Chair

5/20/2023 11


Project Role Name Location Interest in ProjectPrimary Members(They are experts in their specific skill areas. Devote at least 50% of their time to the project.)

Tom EdwardsJim WastvedtRenee CascioJane DavenportStephen AzumaSuzanne WinsorHelen Miller

Santa FeSanta FeAlbuquerqueBernalilloSanta FeAlbquerqueFarmington

Project DirectorProject ManagerFunctional ManagerFunctional LeadDBATechnical Writer/TrainerUser Lead

Extended members(Their specialized skill is needed at some point in the project. Devote up to 25% of their time to project.)

Jerry WiseJim CoberlyArnold SandovalCourt AdminsChief ClerksFinancial Clerks

Santa FeSanta FeSanta FeVariousVariousVarious

JID Systems MgrSecurity OfficerClient/Desktop LeadAll courtsAll courtsAll courts

Advisory members Phil HedrichFrank DimaggioTBDZella Cox

AlbuquerqueAlbuquerqueAlbuquerqueSanta Fe

Metro Court2nd DistrictJISC projectMuni Courts

5/20/2023 12


4.3.1 P4.3.1 PROJECTROJECT T TEAMEAM O ORGANIZATIONALRGANIZATIONAL B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE

5/20/2023 12


4.3.2 P4.3.2 PROJECTROJECT T TEAMEAM R ROLESOLES ANDAND R RESPONSIBILITIESESPONSIBILITIES

The Project Organization identifies the reporting relationship for the roles of the project. The key project members must understand their duties and responsibilities for a project to be successful. The standard duties and responsibilities of the sponsor, steering committee members, project manager, team leads, and team members are defined below.

Steering CommitteeThe Steering Committee is made up of the Key decision maker(s) on the project. It is typically the sponsor and 2 to 6 other key personnel associated with the project, its funding stream, and/or senior management of the resource pool. The role of the Steering Committee members is to provide overall project direction, make key project decisions, grant final approval of business policies, and approve and accept deliverables.

Project Sponsor The Project Sponsor’s role is to ensure project requirements are identified and support funding initiatives, where required. The Project Sponsor is expected to champion the project.

Project Manager The Project Manager’s role is to provide leadership and management necessary to achieve the project’s success. The project manager is responsible for hands-on project supervision and to direct team activities. The project manager reports to the Steering Committee.

Team Leaders (Primary team members)The Team Leaders are responsible for the development and evaluation of work packages/activities/ tasks, work effort, and task dependencies to complete the scope of the team assignment. They report to the Project Manager.

Team Members (Secondary and Extended team members)

Team Members are responsible for validation of the work packages/activities/ tasks, work effort, and task dependencies and for execution of them to complete the scope of the team assignment. They report to a Team Leader or the Project Manager. Contractors are typically secondary or extended team members and report to an engagement manager of the contractor or to the Project Manager.

5.0 P5.0 PROJECTROJECT M MANAGEMENTANAGEMENT ANDAND C CONTROLSONTROLS

5.1 S5.1 STAFFINGTAFFING P PLANNINGLANNING ANDAND A ACQUISITIONCQUISITION

5/20/2023 13


Although vendor staffing is dependent on the vendor and product selected, there are key internal business and technical functions that need to be performed by court staff that are not dependent on the vendor. These functions include, but are not limited to the following: in-house project management (may be augmented by contract resources) setting control and code table codes and functions for New Mexico courts data migration/conversion mapping between existing and new database data

elements development of training curriculum and modification of vendor training materials conducting training (with vendor assistance) user and acceptance testing The details of a full staffing plans will be developed and negotiated once a vendor is selected through the RFP process.

5.2 A5.2 ASSUMPTIONSSSUMPTIONSThe detailed assumptions and constraints will be developed once a vendor is selected through the RFP process. The initial internal assumptions and constraints are identified below.


ASM-01 Staff (JID and Court) will be available when needed on the projectASM-02 Key technical functions will be supplemented by contract resourcesASM-03 Retention of key JID staff can be maintainedASM-04 Adequate funding will be appropriated/available when neededASM-05 Platform/environment will be available at start of projectASM-06 Framework/methodology will be adopted easily by technical staffASM-07 TBD

5.3 C5.3 CONSTRAINTSONSTRAINTS


CNS-01 Pilot must be installed by December 31, 2008CNS-02 Statewide rollout completed by September 30, 2010CNS-03 Application must function within the physical constraints of the existing

network environmentCNS-04 TBDCNS-05 TBD

5.4 D5.4 DEPENDENCIESEPENDENCIESTo be developed once a vendor is selected through the RFP process.

5/20/2023 14


5.4.1 M5.4.1 MANDATORYANDATORY D DEPENDENCIESEPENDENCIES


MANDEP-01 Signed contract with selected vendorMANDEP-02 IV&V contract executed MANDEP-03

5.4.2 D5.4.2 DISCRETIONARYISCRETIONARY D DEPENDENCIESEPENDENCIES


DISDEP-01DISDEP-02DISDEP-03

5.4.3 E5.4.3 EXTERNALXTERNAL D DEPENDENCIESEPENDENCIES


EXTDEP-01EXTDEP-02EXTDEP-03

5.5 R5.5 RISKISK M MANAGEMENTANAGEMENTAn appropriate methodology used by experienced managers will guide the identification and analysis of risks and assist with the development of effective risk management strategies. The Project Manager will create a Risk Mitigation Plan that will follow the model developed by PMI.

5.5.1 R5.5.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGYThe Project Manager will be responsible for managing risk identification, assessment, monitoring, mitigation, and contingency planning. The Project Manager will assign and include specific Risk Identification tasks in the Implementation Schedule. The Project Manager will actively solicit and document input about potential risks from all stakeholders related to specific business functions affected by the Case Management Application Project. Project Status Reports and Risk Management Reports will be updated monthly, or more frequently if needed, with new and escalating risk profiles, mitigation strategies and treatment plans.

5.5.2 P5.5.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATIONRisk Identification consists of determining which risks are likely to affect the project and documenting the characteristics of each. Risk identification is not

5/20/2023 15


a one-time event but an iterative process. The Risk Assessment Model will be utilized on the project to identify and analyze risks.

Risk Identification categorizes specific project risks within broad categories. The following categories will be used for risk categories on this project:

Strategic – risks relating to the purpose and outcomes of the project. Financial – risks relating to the project costs, funding sources,

cost/benefit analysis Resource – risks relating to availability and skill sets of the project

resources Project Management - risks relating to the project management

team’s relevant experience Technology – risks relating to the technology platforms involved in

the project Change Management / Operational Risk – risks relating to user

involvement with and acceptance of the project

One of the initial high level risks identified to date include the potential unavailability of technical, functional, and project management resources when critically needed for the project. This risk will be mitigated by carefully allocating resources to the project and when possible, committing such resources to the project as close to full-time as possible without interrupting operational activities. Ensuring that adequate funding is available to augment these staff resources will enhance the success of the project.

Another risk could result from end-user resistance to change. Because the Judiciary has chosen to purchase and implement an off-the-shelf solution, court users will inevitably experience changes in the look and feel of their case management system. The challenge will be to communicate effectively and often with end users, involve them actively in the project, and ensure that requested customization is made only for mandatory business needs. Effectively managing user expectations regarding any new system will greatly reduce the risk of increasing project scope through excessive customization.

Other risks include risks related to inadequate funding, risks associated with an aggressive implementation schedule, risks associated with system response time limitations in remote areas having only low bandwidth telecommunications, and the risks of integrating existing applications with the new court case management system, including, but not limited to, EDMS at the 2nd District, MyCourt, public case lookup, data exchanges between Bernalillo County Metropolitan Court and law enforcement agencies and MVD.

The chart below summarizes the initial risks identified with the project. The ratings are calculated using variables for likelihood (L) of occurring and impact (I) if they do occur, with 1 = low, 2 = medium, and 3 = high. The rating (R) is an average of the ratings.

Major Risk L I R Mitigation Strategy

5/20/2023 16


Potential unavailability of resources 2 3 H Augment resources, select vendor with experience

User resistance to change 3 2 H User involvement/communication plan

Inadequate project funding 1 3 M Use multi-year phases/reduce scope

Telecommunications/bandwidth 2 2 M Pursue acceleration options

External systems interfaces 2 1 L Extensive integration testing

Scope creep 1 1 L Strong scope/change control process

5.5.3 P5.5.3 PROJECTROJECT R RISKISK A ANALYSISNALYSIS

At the broadest level, almost everything can go wrong on a project. However, the objective is not to cast a pessimistic view of the project, but to identify potential barriers to success so that they can be reduced or eliminated. The goal will be to identify the events that could impact the team’s potential of delivering the project on time, on budget, and with the right features and quality. Once a vendor is selected, additional risks will be identified and risk response and mitigation processes developed.

5.5.3.1 [RISK 1 NAME]Description -. Probability and Impact -

Mitigation Strategy - Contingency Plan -

5.5.3.2 [RISK 2 NAME]Description - Probability and Impact -

Mitigation Strategy - Contingency Plan -

5.5.4 P5.5.4 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH

Each identified risk for the project will be categorized and have one of the following risk responses:Negative Risks Avoidance. The team changes the project plan to eliminate the risk or to protect

the project objectives from its impact. The team might achieve this by changing scope, adding time, or adding resources (thus relaxing the so-called “triple constraint”). These changes may require a PCR.

Transference. The team transfers the financial impact of risk by contracting out some aspect of the work. Transference reduces the risk only if the contractor is more capable of taking steps to reduce the risk and does so.

5/20/2023 17


Mitigation. The team seeks to reduce the probability or consequences of a risk event to an acceptable threshold. They accomplish this via many different means that are specific to the project and the risk. Mitigation steps, although costly and time-consuming, may still be preferable to going forward with the unmitigated risk.

Acceptance. The project manager and the project team decide to accept certain risks. They do not change the project plan to deal with a risk, or identify any response strategy other than agreeing to address the risk if and when it occurs.

Positive Risks Exploit – Increasing the opportunity by making the cause more probable Enhance – Increasing the expected time, quality or monetary value of a risk by

increasing its probability or impact of occurrence Accept – The project manager and the project team decide to accept certain

risks. They do not change the project plan to deal with a risk, or identify any response strategy other than agreeing to address the risk if and when it occurs. “Sharing – Retaining appropriate opportunities or parts of opportunities instead of attempting to transfer them to others

5.5.5 R5.5.5 RISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY

This project will use the Risk Register in Appendix C for risk reporting. If the project team cannot address a risk, it will be escalated and presented to JIFFY for a risk mitigation strategy.

5.5.6 P5.5.6 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH

The project will use a Risk Register to track risks. The Risk Register form can be found in Appendix C. Project status meetings will include a review of the project risks determining whether the mitigation strategy is working and if the risk needs to be escalated. This documentation will be maintained in the project library.

5.6 I5.6 INDEPENDENTNDEPENDENT V VERIFICATIONERIFICATION ANDAND V VALIDATIONALIDATION - IV&V - IV&VThe Project will engage an independent IV&V and contractor selection is underway to hire a contractor. The IV&V contractor will review the project processes and deliverables, attend meetings as required (JIFFY and Steering Committee Meetings, Project Team Meetings) and provide a monthly report to JIFFY.

Risks have initially been documented in this project management plan. These are reviewed and tracked on a regular basis with the project team and JIFFY. The IV&V contractor will deliver an initial risk assessment as part of their IV&V plan. Independent Verification and Validation on the project will provide project oversight through an independent evaluation of the products and process quality of the project. An IV&V plan will be developed to provide the following deliverables:

5/20/2023 18


1. Initial Risk Assessment.2. Initial Status Report to disclose the effectiveness of project

management and whether project activities are meeting the objectives set forth by the STREOC.

3. Interim reporting for each rollout based on project schedule and project deliverables.

4. Final end-of-contract assessment, “close-out” report.

For the project, IV&V functionality will be incorporated once an IV&V vendor has been selected and a contract signed. The scope of activity for IV&V will include the following tasks that will be more discretely defined in the contract scope of work.

1. Become familiar with the project and overall New Mexico courts through review of application documentation, project documentation and JIFFY meeting minutes.

2. As required, interview project team members to answer questions raised during the initial discovery phase of the engagement

3. Review Project Management Plan (PMP) and provide feedback as appropriate.

4. Prepare an overall IV&V project assessment on a monthly basis for JIFFY and the State CIO.

Final format and outline to be defined with the assistance of the IV&V contractor after the engagement is initiated

Concurrence on IV&V reporting and format will be obtained from JIFFY

This will be an IV&V only report—most status will be reported in the normal manner to JIFFY.

As required, escalate issues to the Program Director as they are discovered.

Logistics assumptions for the IV&V engagement follow:1. IV&V consultant(s) will participate on a part time basis2. IV&V consultant(s) will work onsite at JID unless otherwise

authorized3. Initial engagement will start with one consultant.4. Anticipate IV&V activity will start in 2nd Q FY2008.5. Initial engagement is expected to be at least one year in

duration.

5.7 S5.7 SCOPECOPE M MANAGEMENTANAGEMENT P PLANLANWith any project, no matter how comprehensive the planning process, changes arise that need attention. This section of the project plan addresses how issues are managed and changes are controlled for the Case Management System project. The Scope Change Management Plan will have steps in handling scope change. Scope Change Control forms

5/20/2023 19


are obtained (with signatures) and the Project Manager will be responsible for maintaining a log of such approvals. The following steps will be included in the plan.

A potential change in the project scope is identified. The potential change is reviewed. If it is not considered beneficial to the success

of the project but will impact the project result if left unattended, an issue is recorded in the Issues Management Process.

The change is then evaluated. If there is no impact on the project deliverables, budget or the schedule, the change is made and documented. Otherwise the calculations are made and the Change order Form is completed.

The Scope Change Control form is reviewed by the Project Team and/or the Change Control Board. If the change is approved it is implemented and then documented.

If the change is not approved, there must be something that needs to be resolved, an Issue is raised and resolved through the Issue Management Process.

5.8 I5.8 ISSUESSUE M MANAGEMENTANAGEMENTWhen the project team identifies an issue, it is added to Team Track. An issue can be identified by anyone affiliated with the project, although entry in Team Track must be done by an authorized licensee of Team Track.

The project team is primarily responsible for tracking issues from the time of identification through resolution. The project team will review the issues list weekly. Issues with potential to negatively affect the project are brought to the attention of the Steering Committee according to the change control process described in section 5.10. The process of tracking an issue is as follows:

Issue is identified. Issue is entered on Team Track (Item Type, Title, Description) and submitted to

the manager of the section responsible for coordinating resolution of the issue. The manager may re-assign the issue to a section employee.

At completion, the actual completion date and issue resolution is documented.

Examples of issue resolutions are described below: With the proper approval, the issue becomes a task added to the project plan, if

new and/or within scope of the project. Issue is resolved by prescribed action taken. The issue is addressed by means of a specific written document. The issue is addressed by creation of a new documented policy or procedure.

The project team has primary responsibility for resolution of issues and/or follow-up to ensure correct action is taken.

Additional detailed internal and external escalation procedures will be negotiated with the selected vendor once the RFP process is completed.

5/20/2023 20


5.8.1 I5.8.1 INTERNALNTERNAL I ISSUESSUE E ESCALATIONSCALATION ANDAND R RESOLUTIONESOLUTION P PROCESSROCESS

Issues that involve project resources, processes, procedures, or methodology will be resolved within the AOC. JIFFY and other stakeholders on the project may submit a Team Track request to document an issue. The key purpose in having an issue escalation and resolution process is to use it for improving project processes as the project is executed versus waiting until lessons learned are discussed during project closure.

Issues within this project will be discussed during the weekly project status meetings and monthly JIFFY meetings. Any issues that cannot be resolved by the Project Manager with the project team will be escalated to JIFFY for approval.

5.8.2 E5.8.2 EXTERNALXTERNAL I ISSUESSUE E ESCALATIONSCALATION ANDAND R RESOLUTIONESOLUTION P PROCESSROCESS

The same escalation and resolution process steps in 5.8.1 above will be used for external issues relating to the project. The only difference between the internal and external escalation and resolution processes would be the level of involvement of the management team from a particular agency or stakeholder organization to handle issues that involve project resources, processes, procedures, or methodology that cannot be resolved within the project team.

5.9 P5.9 PROCUREMENTROCUREMENT M MANAGEMENTANAGEMENT P PLANLANProcurements under $30,000 will follow normal Administrative Office of the Courts (AOC) purchasing policies and procedures. Procurements over $30,000 will follow the State’s RFP procurement process or use of state-wide price agreements. The AOC also follows a new IT software and equipment policy that was approved by JIFFY in May 2007. This policy requires any IT purchases over $2,500 to be reviewed and approved by JIFFY before purchase.

5.10 C5.10 CHANGEHANGE C CONTROLONTROLA change control process is an essential component of a successful IT project. The key to controlling project change is management of the impact of necessary changes on the project plan, budget, and implementation schedule.

Some changes are unavoidable – as in, instances where changes must be made to comply with Supreme Court or local rules, individual court policies and procedures with regard to its business functions, state legislative mandates, or anywhere else where Court needs necessitate technology change and/or enhancement. Any non-essential changes can be avoided through management of a formal change control process.

Changes can occur insidiously, such as through Scope changes (sometimes referred to as “scope creep”). Scope creep is the continual addition of functional enhancements to the product requirements throughout the project life cycle. Excessive scope changes are directly related to poorly defined product requirements and specifications. A well thought out change control process will assist the project management team in controlling “scope creep”.

5/20/2023 21


Three (3) steps are necessary to control scope changes: Establish the baseline product. Obtain agreement from the project “approvers”. Enforce a formal change control process.

5.10.1 C5.10.1 CHANGEHANGE C CONTROLONTROL P PROCESSROCESS

All proposed changes are submitted to the project manager. The project manager may assign the change evaluation to a project team or to individual project member. Change requests that materially affect the project schedule, cost, quality, or risk are submitted to the Steering Committee for final approval.

TEAM TRACK CHANGE REQUESTA Team Track Change Request is used for all change requests associated with the CMS Project. Anyone on the project team or Steering Committee may initiate a change request.

To initiate a change request, the requestor writes a brief description of the proposed change and collects any associated materials. If the change is to fix a problem, samples demonstrating the problem should be attached to the change request form. If the request is for an enhancement, the requestor must give as much detail as possible about the proposed enhancement.

IMPACT ESTIMATEOnce the change request is initiated, a Change Request Impact (Appendix “?”) is completed and forwarded to the Project Manager. The Project Manager reviews the request, establishes a preliminary project size and priority, and delegates it to a team or individual for a more thorough assessment of impact.

If the preliminary estimate of the project size affects either the schedule, costs, quality, or risk of the project, the Project Manager will refer the issue to the Steering Committee for review and approval. If the estimate does not affect negatively, the Project Manager will inform the Steering Committee of the change request at its next scheduled meeting.

Each change request is assigned to the appropriate project team for initial review and estimate. Each change request contains the following information for review:

Overview: A brief description of the change request. This might be as simple as a prioritized, short list or a complete list of the tasks to be accomplished. This also might include a review of the current process, include statistical data (e.g. transaction volumes), and any other impact.

Statement of Need: A brief description of why the current process is not providing the users what they need. This could be something as specific as a regulatory rule change, or something as general as the user's impression that the process is too cumbersome or takes too long to perform.

5/20/2023 22


Requirements: Detailed statement(s) of the user’s requirements. Requirements must be stated in specific terms of results and/or output expected. Too generic statements can only lead to misunderstanding and re-work.

Impact: A preliminary estimate of the project size/staff and other resources needed to support the change. This should include a preliminary estimate of change risk, and a preliminary estimate of change benefits; benefits can be quality and/or politically oriented as well as financially related.

5.10.2 C5.10.2 CHANGEHANGE C CONTROLONTROL B BOARDOARD (CCB) (CCB)The Project Manager will veto or approve and prioritize changes as long as there is not an affect on the project schedule, costs, quality, or risks. If a change has an impact on any one or more, a change request is referred to the Steering Committee for a decision. The Steering Committee’s basis for decisions will be in the following priority:

Comply with project goals and objectives Affect on project schedule Affect on project costs

The Steering Committee may refer a change back to the committee for additional information, additional options, or to make the decision based on the change request’s technical merits.

5.11 P5.11 PROJECTROJECT T TIMELINEIMELINEThe target schedule for the project is implementation by December 31, 2009 to ensure the maximum opportunity to maximize identified cost savings. Any schedule delays into the new fiscal year, FY08, increases the agencies risk of not having enough funding to support on-going services. The major milestones to accomplish the date include the following: RFP released on May 18, 2007 Contract award September 2007 Vendor/Judiciary Planning December 2007 Fit Analysis March 2008 Installation, configuration, and training September 2008 Pilot courts March 2009 Statewide Installation December 2010

The project will be broken into four (4) major phases. Each phase will include at least one major milestone. The major phases, their description, and the initial milestone follows:

Conceptual/Initiation PhaseThe focus in this phase is on defining the project and getting the project underway. The problem addressed by the project is clearly stated; project goals and objectives are identified. Project assumptions, constraints, and risks are defined and documented. The focus is on "what" needs to be accomplished not "how" it will be done. The initial milestone for this phase will be the RFI, site visits and release of the RFP.

5/20/2023 23


Start - 3/2007: Finish – 9/2007

Planning PhaseProject Planning defines in detail the project activities and the product(s) that will be produced, and describes how the project activities will be accomplished. Project Planning defines all major tasks, estimates the time and resources necessary to complete them, and provides a framework for management review and control. The initial milestone for this phase will be the Project Plan.Start – 10/2007: Finish – 12/2007

Execution PhaseOnce a project reaches the Execution Phase, the project team and the necessary resources will be in place and ready to perform the project activities. The Project Plan is finalized and baselined. The focus of the project manager, as well as the team, shifts from planning to participation in, monitoring, and analyzing planned activities. The preliminary milestones for this phase will be the Implementation/Migration Plan Document, Pilot Installation, and statewide implementation.Start - 1/2008: Finish – 12/2010Close Out PhaseThis is the process that is performed when all project objectives have been met and the system has been accepted by the requestor. Formal system acceptance is necessary to determine whether the system was built according to its functional requirements and operates as designed. The initial milestones for this phase will be the User Acceptance Signoff, Lessons Learned Document, and Contract Closure.Start - 1/2011: Finish - 2/2011

5.12 P5.12 PROJECTROJECT B BUDGETUDGET

Phase / Activity Associated Deliverables Estimated Budget

Umbrella Tasks IV & V TBD

Phase 1Project Preparation & Planning

Project Plan and scheduleRFI RFP Document

Expended out of FY07 general fund appropriation

Phase 2Project Execution

Software LicensingHardware/Database/InfrastructurePilot Installation/Integration/Migration/Conversion/TrainingOther (maint, travel, IV&V, etc.)

$3,360,000$ 252,000$2,205,000$ 183,000

Phase 3Implementation

Statewide Implementation/Migration/Conversion/Training $4,000,000(FY09 request)

Phase 4Project Closing

User SignoffContract Closure

Internal funds out of operating budget

TOTALS $10,000,000

5/20/2023 24


5.12.1 B5.12.1 BUDGETUDGET T TRACKINGRACKING

Budget tracking will be addressed through the existing JID/AOC budget process and also will include the budget tracking reports available in Microsoft Project.

5.13 C5.13 COMMUNICATIONOMMUNICATION P PLANLANThe Communication Plan "defines the information and communications needs of the project stakeholders: who needs what information, when will they need it, and how will it be given to them." The plan contains most, but not all, communications activities that will occur throughout the project. Informal communications should occur and are encouraged. Responsible Party - refers to who is involved in the communication process – the

identified stakeholders such as project management and staff, customer management and staff, and external stakeholders.

Communication - refers to what is being communicated – the message, the information being communicated.

Frequency - refers to when the information is communicated – weekly, monthly, quarterly, as needed or as identified.

Media - refers to how the information is disseminated – in a meeting, a memorandum, an email, a newsletter, or a presentation.

Approval Authority – refers to the entity that must adopt/endorse/approve the communication before it is distributed or published.

5/20/2023 25


5.13.1 C5.13.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

Communication Responsible Party Audience Frequency Media Approval Authority

Project Documents Project Manager Steering CommProject Team

At Initiation through establishment of Baseline Word Doc Steering Comm

Meetings Project ManagerTeam Leads

Project TeamsTeam Members

Weekly, Monthly, or as needed

In personIn Person Steering Comm

Status Reports Project ManagerProject Teams

Steering CommProject Manager Monthly Word Doc Project Manager

Project Issues AnyoneSteering CommProject ManagerProject Teams

Anytime Team Track No impact - PMImpact - Steer Comm

Change Requests Team Leads

Project ManagerSponsor

Steering CommProject Teams

As needed Change OrderSteering Comm

SponsorProject Manager

Project Updates Project Manager Team Lead(s)

Steering CommSponsor

Quarterly or as needed/requested Written, or verbal Sponsor

5/20/2023 26


5.13.2 S5.13.2 STATUSTATUS M MEETINGSEETINGS

Status meetings will be held weekly and follow an agenda supplied at least 1 business day prior to the meeting. The meetings will focus on assigned tasks due for the period. Issues can be raised at the meeting, but they will be resolved through the issue process outside of the status meetings

5.13.3 P5.13.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

Project team members will provide weekly status reports to the project manager, emphasizing tasks assigned for the period. The project manager will provide summary status reports to the project sponsor/owner monthly, and as requested by the sponsor/owner.

5.14 P5.14 PERFORMANCEERFORMANCE M MEASUREMENTEASUREMENT (P (PROJECTROJECT M METRICSETRICS))The primary project measurement will focus on Earned Value, which also assesses progress and provides trending attributes that will help track and project time and cost impact of schedule differences. Success criteria at the end of the project will be based on the objectives of the project, which include the following:

Implement a Case Management pilot by December 31, 2008. Reduce current costs of multiple Case Management Systems and databases. Reduce down time and staff recovery effort resulting from synchronization issues.

Improve productivity of court staff from use of scheduling module, error reduction, and reducing training travel costs.

Provide 99.9% system availability, including remote access.

5.14.1 B5.14.1 BASELINESASELINES

A baseline of the project plan will be established once the by the appropriate project governance. The baseline will not change unless there is a scope change.The CMS project plan is developed around the usable functionality of the existing FACTS Case Management System. No functional enhancements are planned to the new system unless they can be developed for the same or less cost/time as it would take to produce the same functionality provided by FACTS. The Charter’s scope of work, plus the Work Breakdown Structure and product descriptions in section 6.1 of this document, represents the baseline product and, therefore, the criteria for determining the approved scope

5.14.2 M5.14.2 METRICSETRICS L LIBRARYIBRARY

All project documentation will be maintained on Twiki (see Configuration Management section below).

5.15 Q5.15 QUALITYUALITY O OBJECTIVESBJECTIVES ANDAND C CONTROLONTROLThere will be heavy resistance from end-users in having to change case management systems. At a minimum, at least 500 staff will have to change systems no matter which vendor is selected. The active and passive resistance will be significant. The quality strategy will need to address this likely issue in a thorough quality plan.

5/20/2023 27


The purpose of the quality plan is to describe how the project will implement its quality assurance activities and defines the processes that will be taken to prevent and remove defects and to ensure customer requirements are met. At a minimum the quality plan will:

Identify the individuals responsible for quality assurance activities, List the quality factors, Specify the quality standards and procedures to be used by the project, Describe the quality processes that will be used (for example, reliability testing

and/or usability reviews), Describe how the quality plan will be integrated with the project, Describe how the data will be collected and used in a cycle of continuous

improvement.

5.15.1 C5.15.1 CUSTOMERUSTOMER S SATISFACTIONATISFACTION

As stated in A Guide to the Project Management Body of Knowledge, 3rd Edition, p. 196, “Customer Satisfaction is understanding, evaluating, defining, and managing expectations so that the customer requirements are met. This requires a combination of conformance to requirements (the product must produce what it said it would produce) and fitness for use (the product or service must satisfy real needs).

For the project, the following table maps the key requirements for each stakeholder group to result in customer satisfaction. Feedback will be regularly solicited and collected from the stakeholders.

CUSTOMER KEY REQUIREMENTS FOR CUSTOMER SATISFACTION Project meets work plan and schedule stays within budget; with

project status communicated on a regular basis. Selected equipment and software performs as expected raining is effective and receives a good or better rating from

court staff Enhanced data lookup & reporting Increased data accuracy Increased electronic transmission of data Continuous improvement of existing systems Increased and timely accessibility to data

5.15.2 D5.15.2 DELIVERABLEELIVERABLE D DEFINITIONEFINITION

The project deliverables are listed and described in Section 2.3 of this document. Each deliverable will follow a formal review process to ensure that it conforms to the initial definition. Reviewers include but are not limited to the project team, Project Manager, JIFFY, and the IV&V consultant for completeness and acceptance.

5.15.3 D5.15.3 DELIVERABLEELIVERABLE Q QUALITYUALITY

5/20/2023 28


The quality of each of the deliverables will be measured through several ways. The criteria for the quality of each of the Project Management deliverables is described in section 2.3.

5.15.4 P5.15.4 PROJECTROJECT/P/PRODUCTRODUCT D DELIVERABLEELIVERABLE P PRESENTATIONRESENTATION

Deliverables will be formally presented at JIFFY meetings.

5.16 C5.16 CONFIGURATIONONFIGURATION M MANAGEMENTANAGEMENTConfiguration management is required to maintain project integrity and, specifically, to do the following:

Provide a disciplined and documented establishment of configuration items and control changes to them.

Ensure proposed changes are adequately assessed and responded to. Ensure changes are approved by the appropriate organizations. Prevent unauthorized changes from affecting the project. Accomplish the timely and accurate incorporation of approved

changes. Ensure that accurate technical documentation is available to develop

and maintain project outputs and deliverables. Define the process for tracking documentation, software, and hardware

throughout the implementation process.

The Project Manager together with the project team will maintain the guidelines for configuration management.

5.16.1 V5.16.1 VERSIONERSION C CONTROLONTROL

Led by the Project Manager, the project team will design and approve the file naming convention to be used for versioning all project documentation. Working versions as well as final, approved versions of documentation and deliverables will be maintained in the project repository. Each work product will be placed under configuration management once it has been “base lined” or initially created. Versions of a work product are tracked from the original baseline.

5.16.2 P5.16.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))A TWiki project repository is in process as part of the project. Approved and baselined project documentation and deliverables will be accessible through the TWiki website.

6.0 P6.0 PROJECTROJECT C CLOSELOSEThe Project Close activities will include administrative project activities and project agreement/ contractual project activities. Completing both sets of

5/20/2023 29


activities is a mandatory step in the project life cycle. Administrative activities complete the internal needs for the project manager, such as lessons learned, recording the last hours against the project, and providing transition for the staff to other assignments. Contractual activities meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products.

6.1 A6.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSEThe administrative closure activities that the Project will perform are the following. It is expected that the IV&V consultant will have an active role in administrative closure of the project.

Ensure all deliverables have been approved –Review each deliverable as specified in the project scope in this project management plan and acceptance forms.

Verify all project documentation has been completed and archived – Review the project repository and ensure all project documentation has been archived for required retention period. This includes providing a final electronic copy of the project files stored on the TWiki web site

Set up and conduct a “Project Review” meeting – This post mortem meeting will be conducted with the project team and JIFFY to identify and review all lessons learned.

Verify formal acceptance has been written and delivered – IV&V consultant will assist in this task.

Reallocate resources – Ensure project staff is transferred from project.

Document project closure to DoIT – Complete OCIO Project Closeout form and attain approval for closeout

6.2 C6.2 CONTRACTONTRACT C CLOSELOSEContract close-out activities are similar to administrative closure in that it involves ensuring that all work products have been completed correctly and satisfactorily and project records have been checked to reflect final results. Contract files will be archived. Typically, the contract will outline the specific guidelines for contract close-out. All contract deliverables must have been completed and accepted and all invoices received and paid. A formal written acceptance and project closure will be prepared and sent to JIFFY.

7.0 G7.0 GLOSSARYLOSSARY

5/20/2023 30


7.1 A7.1 ACRONYMSCRONYMS ANDAND A ABBREVIATIONSBBREVIATIONSAOC Administrative Office of the CourtsCIO AOC Chief Information OfficerDoIT Department of Information TechnologyPMI Project Management Institute.PMBOK Project Management Body of KnowledgePMP Project Management PlanQM Quality ManagementWBS Work Breakdown Structure

7.2 D7.2 DEFINITIONSEFINITIONS

Acceptance Criteria

The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity.

Acceptance Testing

Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.

Assumptions

Planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here, or converted to formal risks.

Baseline

A specification or product that has been formally reviewed and agreed upon that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

Commitment

A pact that is freely assumed, visible, and expected to be kept by all parties.

Configuration Management (CM)

A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.

Constraints

Factors that will (or do) limit the project management team’s options. Contract provisions will generally be considered constraints.

Contingency Planning

The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.

Crashing

5/20/2023 31


Taking action to decrease the total duration after analyzing a number of alternatives to determine how to get the maximum duration compression for the least cost.

Critical Path

The series of activities that determines the duration of the project. The critical path usually defined as those activities with float less than or equal to specified value often zero. It is the longest path through the project.

Dependencies, Discretionary

Dependencies defined by the project management team. They should be used with care and usually revolve around current Best Practices in a particular application area. They are sometimes referred to as soft logic, preferred logic, or preferential logic. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.

Dependencies, Mandatory

Dependencies that are inherent to the work being done. In some cases, they are referred to as hard logic.

Dependency Item

A product, action, piece of information, etc., that must be provided by one individual or group to a second individual or group so they can perform a planned task.

Deliverable

Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project that is subject to approval by the project sponsor or customer.

Duration

The number of work periods (not including holidays or other nonworking periods) required to complete an activity or other project element.

Duration Compression

Shortening the project schedule without reducing the project scope. Often increases the project cost.

End User

The individual or group who will use the system for its intended operational use when it is deployed in its environment.

Effort

The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks.

Fast Tracking

Compressing the project schedule by overlapping activities that would normally be done in sequence, such as design and construction.

5/20/2023 32


Float

The amount of time that an activity may be delayed from its early start without delaying the project finished date.

Formal Review

A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project.

Integrated Project Plan

A plan created by the project manager reflecting all approved projects and sub-projects.

Lessons Learned

The learning gained from the process of performing the project. Lessons learned may be identified at any point during the execution of the project.

Method

A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result.

Methodology

A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a product.

Milestone

A scheduled event for which some individual is accountable and that is used to measure progress.

Non-technical Requirements

Agreements, conditions, and/or contractual terms that affect and determine the management activities of an architectural and software project.

Performance Reporting

Collecting and disseminating performance information. This includes status reporting measurement, and forecasting.

Procurement Planning

Determining what to procure and when.

Product Scope

The features and functions that characterize a product or service.

Project Leader (Technical)

The leader of a technical team for a specific task, who has technical responsibility and provides technical direction to the staff working on the task.

Project Management

5/20/2023 33


The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project Management is also responsible for the oversight of the development and delivery of the architecture and software project.

Program

A group of related projects managed in a coordinated way. Programs include an element of ongoing work.

Project Manager

The role with total business responsibility for an entire project. The individual who directs, controls, administers, and regulates a project. The project manager is the individual ultimately responsible to the customer.

Project Charter

A document issued by senior management that formally authorizes the existence of a project. It provides the project manager with the authority to apply organizational resources to project activities.

Project Management Plan

A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost, and schedule baselines. The Project Management Plan (PMP) is a project plan.

Project Schedule

A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. Software products such as ABT’s Workbench and Microsoft Project are tools used to develop project schedules.

Project Scope

The work that must be done to deliver a product with the specified features and functions.

Project Sponsor

The individual that provides the primary sponsorship for an approved project. This individual will play a key role in securing funding, negotiating for resources, facilitating resolution of critical organizational issues, and approving key project deliverables.

Quality

The degree to which a system, component, or process meets specified requirements.

The degree to which a system, component, or process meets customer or user needs or expectations.

Quality Management

5/20/2023 34


The process of monitoring specific project results to determine id they comply with relevant standards and identifying ways to eliminate causes of product non-compliance.

Risk

Possibility of suffering loss.

Risk Management

An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a more accurate understanding of, the risks involved. Risk Management includes risk identification, analysis, prioritization, and control.

Risk Management Plan

The collection of plans that describes the Risk Management activities to be performed on a project.

Risk Management

Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold.

Scope Change

Any change to the project scope. A scope change almost always requires an adjustment to the project cost or schedule.

Stakeholder

Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.

Standard

Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development

Statement of Work

A description of all the work required completing a project, which is provided by the customer.

System Requirements

A condition or capability that must be met or possessed by a system component to satisfy a condition or capability needed by a user to solve a problem.

Subproject

A smaller portion of the overall project.

Task

A sequence of instructions treated as a basic unit of work.

5/20/2023 35


A well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (post conditions). (see activity for contrast.)

Team

A collection of people, often drawn from diverse but related groups, assigned to perform a well-defined function for an organization or a project. Team members may be part-time participants of the team and have other primary responsibilities.

Technical Requirements

Those requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements.

Traceability

The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.

Work Breakdown Structure

A deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.

5/20/2023 36


Appendix A

Work Breakdown Structure

5/20/2023 37


5/20/2023 38


5/20/2023 39


5/20/2023 40


5/20/2023 41


5/20/2023 42


5/20/2023 43


5/20/2023 44


5/20/2023 45


Appendix B

Project Schedule

5/20/2023 40


5/20/2023 41


Appendix C

PM Forms

5/20/2023 42


PROJECT SIGNOFF FORMPROJ TITLE: PROJECT #:

PHASE/ITEM: CHARTER PLAN DELIVERABLE

ACCEPTANCE CLOSEOUT ____________ DESCRIPTION:

APPROVED: YES YES: CONDITIONAL (Requires Conditions) NO: (Requires Comments)

CONDITIONS/COMMENTS:

SIGNATURE: TITLE:

DATE:

SIGNATURE: TITLE:

DATE:

SIGNATURE: TITLE:

DATE:

5/20/2023 43


PROJECT STATUS REPORT

PROJECT/WO #: RESOURCE: _

REPORT PERIOD: REPORT DATE: _

DESCRIPTION: _

SCHEDULED TASKS/ACTIVITIES:

1.

2.

3.

REPORTED PROGRESS:

1.

2.

3.

UNSCHEDULED TASKS:

ISSUES/CONCERNS:

NEXT MILESTONE(S):

1.

2.

3.

5/20/2023 44


Change Request Title:

Requester: Date:

Type of Change:

Scope Schedule Cost Other (describe):

Description of Change:

Deliverables (Objectives) Effected: (List deliverables from the project plan that will be impacted by this change)

Anticipated Effect of Change: (What happens if the change is implemented? What happens if the change is not implemented?)

Justification/Cause of Change: (Technology, regulatory or legal, defective hardware or software, new requirements from client)

Cost of Change: (Additional people resources needed, additional time needed, additional dollars needed)

Alternative Solutions:

Notification Review: (Who needs to be notified?):SponsorProject managers of other projects affected by this changeStakeholdersOthers:________________________________________________________________________________________

To Be Completed by Appropriate Manager

Reviewed and Approved By:

Project Sponsor:

Reviewed and Approved By:

Project Manager: Date:

CHANGE REQUEST IMPACT ESTIMATE

5/20/2023 45


The following estimate is presented to the Steering Committee for review. This form is used primarily to document cost estimates at a high level. It is intended to be used to assist management in determining relative impact of change requests and used in establishing priorities of those requests. The cost estimates in no way represent a detailed, fully-burdened financial analysis of the current or proposed processes.

TEAM TRACK #: REQUESTOR:

OVERVIEW/DESCRIPTION:Describe the requested change.

STATEMENT OF NEED: What has caused the request…why is it needed?Include any appropriate statistics or examples that will demonstrate the need.

REQUESTED CHANGE:What specifically is the requested change and what is the recommended solution?

IMPACT:What are the benefits of doing this and why?What is the estimated impact this will have on cost, schedule, quality and risk to the project?

REQUESTER Date: ____________________

PROJECT MANAGER Date: ____________________

JIFFY Date: ____________________

5/20/2023 46


JUDICIAL CASE MANAGEMENT APPLICATIONRisk Register as of [Date]

Report for: Project Manager: Project Goal:

Rating for Likelihood and Impact for each risk

L Rated as Low E Rated as Extreme (Used for Impact only)

M Rated as Medium NA Not Assessed

H Rated as High

Grade: Combined effect of Likelihood/Impact

Impact

Likelihood

low medium high EXTREME

low E D C B

medium D C B A

high C B A A

Recommended actions for grades of risk

Grade Risk mitigation actions

A Mitigation actions to reduce the likelihood and impact to be identified and implemented as soon as the project commences.

B Mitigation actions to reduce the likelihood and impact to be identified and appropriate actions implemented during project execution.

C Mitigation actions to reduce the likelihood and impact to be identified and costed for possible action if funds permit.

D To be noted - no action is needed unless grading increases over time.

E To be noted - no action is needed unless grading increases over time.

Change to Grade since last assessment

NEW New risk Grading decreased

— No change to Grade Grading increased

5/20/2023 47


RISKID

Description of RiskIdentify Consequences

Likelihood Impact Grade Chg Mitigation Actions Responsible Party

Cost WBS

5/20/2023 48


Deliverable Acceptance DocumentFor [Deliverable Title]

This document describes the required contents of a deliverable. Work plans that support the activity summary can be attached, and may be referenced to support the methodology and schedule summary.

IINTRODUCTIONNTRODUCTION[A brief overview defining the purpose of the deliverable and how it fits within the overall completion of the project. Indicate if there are pre-requisite tasks and dependent tasks.]

DDELIVERABLEELIVERABLE D DESCRIPTIONESCRIPTION[Describe the deliverable’s objectives and scope. Discuss the level of detail to be provided such as “will describe the rationale for design decisions, will provide a textual summary of the design with detailed design pseudocode in the appendices, will include database schema diagrams and database table relationships, field sizes and descriptions, and indices and keys”. Discuss the intended audience. If the document assumes a specific knowledge level, list the key concepts that must be understood (e.g., understanding of backup rotation schedules, understanding of registry editing, etc.). Do not use vague terms such as “basic knowledge of system administration”.]

MMETHODOLOGYETHODOLOGY FORFOR C CREATINGREATING THETHE D DELIVERABLEELIVERABLE[Provide a brief explanation of the tasks, activities and methods to be used to develop the deliverable. If appropriate, include a process flow diagram. Do not duplicate methodologies described elsewhere (e.g., if the design methodology was described in detail in the proposal and project management plan, reference the appropriate document section). Indicate if there are any assumptions or constraints on the development of the deliverable.]

AAPPLICABLEPPLICABLE S STANDARDSTANDARDS[List the specific industry and/or judiciary standards, which must be observed. Do not simply list “industry standards” or “IEEE”. Indicate if the format/order of the standard must be observed or if the contractor may provide a mapping of their format to the standard to show compliance.]

DDELIVERABLEELIVERABLE R REQUIREMENTSEQUIREMENTS[List the specific requirements for this deliverable from the Request for Proposal, Statement of Work, contract, and/or project Plan. List the specific source of the requirement, including document name, document date/version, paragraph or page number, and requirement number.]

Table 1. Deliverable RequirementsREQMT

#REQUIREMENT DESCRIPTION SOURCE OF THE

REQMTCOMMENT

DDELIVERABLEELIVERABLE F FORMATORMAT[List any required templates, diagrams, tables or specific content required for this deliverable. For instance in design and test deliverables, an updated requirements traceability matrix should be included in the final deliverable.

5/20/2023 49


Indicate the format of the document and any associated diagrams, spreadsheets (e.g., WordPerfect, MS Word, MS Visio, MS Project, etc.). Estimate the length/size of the document, and number of copies to be delivered.]

DDELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE C CRITERIARITERIA

[List the specific acceptance criteria for the deliverable. The first criteria should always be “were the requirements met”. The criteria should be specific to the deliverable and indicate key needs of the project (e.g., must include detailed description of database sizing, growth considerations, performance considerations, and de-/normalization considerations). Other general review criteria (which are primarily the same for all deliverables) may be referenced or attached. The following are the minimum acceptance criteria.]

Did the deliverable comply with the applicable standards from Section (above)?

Were all requirements from Section (above) met?

Did the deliverable comply with the stated format requirements from Section (above)?

Is the deliverable consistent with other deliverables already approved?

Did the deliverable meet the general review criteria (e.g., pages numbered, free of formatting and spelling errors, clearly written, no incomplete sections, etc.)?

DDELIVERABLEELIVERABLE S SCHEDULECHEDULE

KKEYEY D DELIVERABLEELIVERABLE D DATESATES[List the key activities and due dates in the preparation and review of this deliverable. If appropriate, list key meetings, walkthroughs, inspections and reviews. These tasks should be consistent with the activities and dates in the workplan and contractual timeframes regarding deliverable delivery, review and approval/rejection. Include time for judiciary review of the deliverable and contractor incorporation of comments. Indicate if any activities/dates are on the critical path or have significant dependencies. The following is a sample.]

Table 2. Key Deliverable DatesKEY ACTIVITY DUE DATE COMMENT

Internal Walkthrough with ProjectDraft Deliverable SubmittedJudiciary Review of Draft Minimum of 1 weekWalkthrough of Draft with StakeholdersDeadline for Comments on DraftContractor Incorporation of CommentsFinal Deliverable SubmittedJudiciary Review of Final Minimum of 1 weekDeliverable ApprovalContractor Incorporation of Final Comments (if necessary)

5/20/2023 50


SSCHEDULECHEDULE FORFOR D DELIVERABLEELIVERABLE U UPDATESPDATES[If the deliverable is expected to be updated on a periodic basis, list the proposed schedule of updates and tentative time frames. Dates may be either “hard dates” (e.g., May 5 2004) or “soft dates” (30 days prior to System Test). If appropriate, reference the appropriate RFP/SOW/PP requirement for the update.]

Table 3. Deliverables Update ScheduleREASON FOR DELIVERABLE

UPDATESOW

REFERENCEDATE DUE COMMENT

Incorporate any changes from the Planning, Design, Conversion, Implementation/ Pilot, Test, or Training Phase

[Reference, as used in SOW; i.e. paragraph #, or unique reference]

RRESOURCESESOURCES R REQUIREDEQUIRED[List the specific resources involved in the deliverable preparation and review. Estimate the amount of time required from each key resource, particularly for any sponsor, user, or stakeholder staff involved. If appropriate, list the specific skill or knowledge required, such as knowledge of case management policy or experience with current system’s financial reports. It is not necessary to list all contractor staff involved in the preparation, only the key staff or required skills. This list is not intended to replace the workplan resources, but to identify specific individuals/skills needed to ensure successful completion of the deliverable.]

Table 4. Required ResourcesROLE NAME(S) RESPONSIBILITIES EST. NEED

Deliverable Lead 1 monthDeliverable Approver

5 days

Deliverable Reviewers

7 days

Subject Matter Experts

10 days

Steering Committee/ JIFFY

10 days

DDELIVERABLEELIVERABLE P PAYMENTAYMENT

5/20/2023 51


[If applicable, indicate if this is a payment deliverable, if progress payments for this deliverable will be paid, and the estimated amount for developing this deliverable. If progress payments will be made, estimate the payment schedule. The payment schedule should be consistent with the cost/spending plan.

5/20/2023 52