project management plan · project management plan final - deliverable 4 retiree eligibility...

PROJECT MANAGEMENT PLAN FINAL - DELIVERABLE 4

RETIREE ELIGIBILITY BENEFIT INTAKE SYSTEM (REBIS) UPGRADE AND ENHANCEMENT PROJECT

V 1.3

March 20, 2013 Prepared by:

5971 Jefferson NE, Suite 101 Albuquerque, NM 87109

Phone 505.243.2287 FAX 505.243.4677

Providing solutions for the development, integration, and support of information systems

Project Management Plan

REBIS Upgrade and Enhancement Project Version 1.3

REBIS PMP.docx Page i

REVISION HISTORY

Version Date Pages Affected

Description

V 0.1 12/13/2012 All Initial document draft

V 0.2 12/14/2012

2.0 Project Authority, 5.1 Approach, 7.0 Document Controls, 8 Acronyms

Added introductory paragraph for Project Authority; Reformatted table in 5.1; added link for both SharePoint sites to 7.0; added initial list of Acronyms.

V0.3 12/17/2012

Change Control Process; Deliverable Acceptance;

Updated Change Control Process narrative to be consistent with the contract; added appendix B from the contract so show contract deliverable acceptance process;

V0.4 01/07/2013 Various Sections

Highlighted sections for discussion purposes.


Updates based on meeting with RHCA


Refinement to verbiage in sections reviewed with RHCA.

V0.7 1/15/2013 2.3 Stakeholders

Removed George Lane Name

V0.8 1/17/2013 All Editorial review

V0.9 1/17/2013 All Accepted editorial changes as appropriate; updated stakeholder chart; added section for Product Road Map.

V0.10 1/18/2013 Section 2.7 and Section 5

Updated with milestones, timeline picture, schedule info and status report template

V0.11 1/22/2013 Section 3.2 5.4, and 5.5

Updated with critical success factors, and referenced the SharePoint location where the project schedule will be maintained. Also updated timeline view.

V0.12 1/28/2013 Section 2.7 and 4.1

Updated executive reporting table with #’s and updated status report template; Clarification on Del 1 Acceptance Criteria;

V0.13 1/31/2013 Schedule Updated with current timeline view and schedule information as of today’s date.

V1.0 1/31/2013 New Version No content changes; published as Version 1.0 for delivery



REBIS PMP.docx Page ii

Version Date Pages Affected

Description

V1.1 2/7/2013 Comments from Tiara Grant

V1.2 2/7/2013 Sections 3.1, 3.2, 3.3

Updated with Critical Success Factors and goals. Accepted wording changes in section 3.2.

V1.3 3/20/2013

Section 2.3, 2.4, 2.5, 4.1, 4.2, 5.2, 5.3, 5.5, 5.7

Updated with Product Roadmap, included finalized schedule information, changes with resources, Finalized Document for Delivery



REBIS PMP.docx Page iii

TABLE OF CONTENTS

REVISION HISTORY ....................................................................................................... I

TABLE OF CONTENTS ................................................................................................. III

1 PROJECT OVERVIEW ........................................................................................... 1

1.1 Executive Summary .................................................................................................... 1 1.2 Assumptions ............................................................................................................... 1 1.3 Project Risks .............................................................................................................. 1

2 PROJECT AUTHORITY ......................................................................................... 7

2.1 Project Governance .................................................................................................... 7 2.2 Project Team Organization ......................................................................................... 8 2.3 Project Stakeholders................................................................................................... 8 2.4 Project Steering Committee ........................................................................................ 9 2.5 Roles and Responsibilities of the Project Steering Committee ...................................10 2.6 Roles and Responsibilities of the POD Team ............................................................11 2.7 Executive Reporting...................................................................................................13 2.8 Project Escalation Path ..............................................................................................15

3 SCOPE .................................................................................................................. 16

3.1 Project Goals .............................................................................................................16 3.2 Project Business and Technical Objectives ...............................................................16 3.3 Critical Success Factors ............................................................................................17 3.4 Scope Management Plan ..........................................................................................18

3.4.1 CHANGE CONTROL .................................................................................................................. 18

4 DELIVERABLES / MILESTONES ........................................................................ 20

4.1 Deliverables ...............................................................................................................20 4.2 Milestones .................................................................................................................33 4.3 Deliverable Approval and Acceptance .......................................................................34

5 PROJECT WORK ................................................................................................. 36

5.1 Approach ...................................................................................................................36 5.2 Product Road Map .....................................................................................................40 5.3 Work Breakdown Structure ........................................................................................41 5.4 Schedule ...................................................................................................................42 5.5 Project Timeline View ................................................................................................42 5.6 Project Budget ...........................................................................................................43 5.7 Project Team .............................................................................................................44

6 COMMUNICATION PLAN .................................................................................... 47

7 DOCUMENT CONTROLS .................................................................................... 48

7.1 Document Management ............................................................................................48 7.2 Project Cadence Workbook .......................................................................................50



REBIS PMP.docx Page iv

8 ACRONYMS ......................................................................................................... 51

9 APPENDIX ............................................................................................................ 52



REBIS PMP.docx Page 1

1 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY

The scope of work encompasses the development and implementation of an enhancement to and replacement for portions of the current Retiree Eligibility Benefit Intake System (REBIS), including software and a broad range of professional services. The software source code will become the property of the Retiree Health Care Authority (RHCA) Agency and the State of New Mexico. The professional services shall include but not be limited to analysis and planning, business use case development, design, programming, testing, training (user and technical), operational support, and other professional services directly related to the implementation and operation of the proposed system. In addition, the Contractor shall integrate the current 1,169,915 Agency images into the REBIS interface and link the images to the correct retiree records. The contract shall include a post-acceptance software warranty of 6 months in duration.

1.2 ASSUMPTIONS

Number Description 1. Project staff resources will be available when and as they are needed.

2. Required hardware resources will be available when and as they are needed.

3. Required customer resources will be available when and as they are needed.

4. A significant percentage of the project staff will be experienced with the technical environment.

5. A significant percentage of the project staff will be experienced with the operating system.

6. Issues will be resolved in a timely manner.

7. The project organization described in the project plan will be put in place.

8. Systems components will be capable of being integrated within the IT environment.

9. The scope of the project is limited to that described in the RHCA Charter.

10. Formal procedures for charter and scope change will be followed.

1.3 PROJECT RISKS

Listed below are the initial risks identified for the project. These risks will be monitored on a weekly basis. Mitigation plans will be utilized for those risks that are consider high or show stoppers. A risk and issue log will be maintained throughout the project and will be maintained in the Project Cadence Workbook, which will be stored in the project repository.




# Risk Prob Impact Rating Mitigation Plan

1 NM RHCA operational needs conflict with availability of resources targeted for training.

Expected High 0.5625 • Advance notification of when trainees are needed is communicated in advance • NM RHCA trainees help to ensure that key individuals are not taking vacations or out of office during these periods • Provide multiple training time windows to allow for flexibility by the trainees ~ team will be part of testing/using the system which will help enforce the training/knowledge transfer. ~ modules will be rolled out incrementally so training will also be incrementally. ~ roll out customer service modules in Santa Fe first, then ABQ

2 NMRHCA SME’s not available as needed during aggressive sprint cycles

Possible High 0.2625 • Advance notification of when SME’s are needed is communication • Planning and schedule needs to allow for flexibility • Look for options for fast tracking where the SME’s need to be involved in; helps to cut down on critical path.

3 NMRHCA unable to provide feedback within the timeframes allocated.

Possible High 0.2625 • Advance notification of scheduled time needed by NMRHCA for review and feedback • Advance delivery of pre-draft documents to allow for earlier feedback • Interim reviews of document sections – smaller sections to review – quicker turnaround time • Communication by NM RHCA personnel of planned vacations or periods of unavailability





~ Always provide time as to when feedback is needed

4 Stakeholders not participating in key decision meetings causing delays.

Possible High 0.2625 • Advance notification of planned meetings • Ensuring the stakeholders vacations or periods of unavailability are communicated to the project manager

5 Project Stakeholders not in agreement with requirements as defined during the JADs.

Possible Medium 0.1925 • Ensure stakeholder involvement during the JAD’s • Person representing the stakeholder has authority to make decisions • Stakeholders and their designees roles are clearly defined as part of the project management plan ~ socializing the software with retirees and users in order to ensure their acceptance ~ conduct a special session with Santa Fe after the other sessions are completed to provide additional input and feedback

6 Requirements are not clearly defined such that all Stakeholders understand and are in agreement.

Possible Medium 0.1925 • Complete a detailed requirements traceability matrix with high level and lower level requirements defined at a level that are testable. • Walkthrough with NMRHCA stakeholders to ensure buy in and understanding • Business Use cases cross mapped to the requirements





7 Loss of Key Contractor Personnel

Possible Medium 0.1925 • Ensure that there is cross training between resources • Ensure there is a back-up for all positions • Research replacement options ~ if replacement needed; there would be cross training with existing personnel; reading of existing documentation; kickoff materials accessible; utilization of OneNote for technical team notes; training on TFS environment;

8 Additional requirements are identified too late in the process to allow for incorporation in the schedule

Possible Medium 0.1925 • Ensure there is a freeze point for changes identified in the schedule that is supported by the NMRHCA customer. • Change Management process is defined up front as part of the project management plan to include impact analysis and approvals • Scope needs to be clearly defined in the project management plan ~ incremental deliveries allow for feedback ~ planned an finetuning integration at the end to address

9 Stakeholders are not clear on the critical success factors for the project.

Possible Medium 0.1925 • Critical Success factors defined at the beginning of the project and agreed to by the stakeholders. • Periodic reviews should be included in the Sr. Management briefings to show dashboard indicators relating to the critical success factors.





10 Change Process has not been clearly defined which imposes unreasonable delays in the schedule.

Possible Low 0.1225 • Process and procedures need to be defined, documented and agreed upon at the beginning of the project. • Process needs to be communicated to all • Configuration management tools, processes and procedures defined up front. • A resource has been assigned with configuration management responsibilities.

11 Poor communication between contractor team members.

Unlikely High 0.1125 • Regularly scheduled meetings are defined in the communication plan and executed. ~ OneNote accessible for team information ~ TFS accessible to all team members as well as customer.

12 Scope of the project is not clearly defined or communicated to stakeholders

Unlikely Medium 0.0825 • The scope of the project will be defined as part of the project management plan. • Align the scope of the project management plan to the project charter which has been defined already as part of the PCC process for the State of New Mexico. • Scope will be identified as part of the materials presented during the kickoff meeting • Kickoff meeting should include all project stakeholders, subject matter experts, and stakeholders.




Risks will be ranked by a standardized ranking methodology for probability and impact. The table below shows the values that are used for the computations, where the rating is determined by the Probability * Impact.

Probability Impact Certain (.95) Very High (.95)

Expected (.75) High (.75)

Likely (.55) Medium (.55)

Possible (.35) Low (.35)

Unlikely (.15) Very Low (.15)

Overall ranking of the risks will be categorized as follows:

• Minimum Risk – Acceptable

• Some Risk – Monitor at PM/Team Level

• High Risk – Active monitoring and ongoing contingency/mitigation activity

• Show Stoppers – Active participation with Steering Committee to mitigate

For all risks with a ranking of High or Show Stopper, detailed mitigation and contingency strategies will be developed by the risk owner only.

0.95 0.1425 0.3325 0.5225 0.7125 0.9025

0.75 0.1125 0.2625 0.4125 0.5625 0.7125

0.55 0.0825 0.1925 0.3025 0.4125 0.5225

0.35 0.0525 0.1225 0.1925 0.2625 0.3325

0.15 0.0225 0.0525 0.0825 0.1125 0.1425

0.15 0.35 0.55 0.75 0.95

Pro

bab

ility

Impact




2 PROJECT AUTHORITY

The sections below explain how RHCA and POD will run the project. Included is an overall organizational chart showing the project governance from a high-level perspective. There is a project team organization chart that shows the working relationships within the Scrum environment, along with the specific names of the project stakeholders and the Project Steering Committee members. The roles and responsibilities of the Project Steering Committee and the POD team are delineated. In addition, there are definitions for executive reporting and the escalation path for issue resolution.

2.1 PROJECT GOVERNANCE

Board of Directors

Executive SponsorMark Tyndall

Steering Committee

Project SponsorTomas Rodriguez

RHCA Project Director

Tiara Grant

RHCA SME’s

POD Management Team

Atkinson / Neitzey

POD Technical Leads King / Newquist

POD Development Team




2.2 PROJECT TEAM ORGANIZATION

Development

Team

Technical

Leadership

Management

Team

RHCA Team /

Stakeholders

Retiree Eligibility Benefit Intake System (REBIS)

Project Organization

Technical Lead

Newquist

Product Owner/

Company Exec

King

Project Manager

Neitzey

Principal Investigator

Atkinson

2.3 PROJECT STAKEHOLDERS

ORGANIZATION NAME MAIN RESPONSIBILITY

RHCA Celeste Debari Customer Service / Project Tester

RHCA Jason Ballard Customer Service / Project Tester

RHCA Kimberley Scott Customer Service Director

RHCA Mark Tyndall Executive Director




ORGANIZATION NAME MAIN RESPONSIBILITY

RHCA Shellie Miyaji-Garcia Customer Service / Project Tester

RHCA TBD HR Director

RHCA TBD Financial Specialist

RHCA TBD Chief Financial Officer

RHCA Tomas Rodriguez RHCA Project Sponsor and Primary POC / Steering Committee Chair

RHCA Valerie Krantz-Burge Information Systems / Systems Analyst

RHCA Retirees

RHCA Users

RHCA IT Staff

2.4 PROJECT STEERING COMMITTEE

Listed below are the names of the Steering Committee. They are listed as either participating (P) or as voting (V) members.

ORGANIZATION NAME MAIN RESPONSIBILITY Steering

Committee

RHCA Anna Arellanes Finance P

POD Chris Neitzey Contractor PM P

RHCA Jennifer Mills Information Systems P

RHCA Kimberly Scott Customer Service Director V

RHCA Ramona Martinez Public Outreach V




ORGANIZATION NAME MAIN RESPONSIBILITY Steering

Committee

RHCA TBD Chief Financial Officer V

RHCA David Archuleta Deputy Director V

RHCA TBD Board Member V

RHCA Tiara Grant Project Director P

RHCA Tomas Rodriguez RHCA Project Sponsor and Primary POC / Steering Committee Chair

V

RHCA Valerie Krantz-Burge Information Systems / Systems Analyst

P

2.5 ROLES AND RESPONSIBILITIES OF THE PROJECT STEERING COMMITTEE

Role Responsibility Name

Chair / Project Sponsor

Champions the project by ensuring that the direction of the project continues to be in line with the original mission and goals set forth at the beginning of the project.

Facilitates resolution of issues of the project.

o Allocates the project budget. o Is responsible for the delivery of the project

within approved scope, timescales, and budget.

o Communicates the status of the project to senior management.

o Delivers regular feedback on performance and expectations to the project team.

o Provides input for the Project Director’s and Project Manager’s periodic appraisal.

o Keep members on task and discussions productive.

Tomas Rodriguez

Project Director Oversees the project activities.

Works closely and assists the Contracted Project Manager in the day-to-day management of the project against the approved project plan, budget and scope to deliver the specified objectives and benefits.

Reports on the status of the project to the Steering

Tiara Grant, NM Abilities.




Role Responsibility Name

Committee.

Ensures that the project is resourced properly and efficiently.

Aids in the evaluation and mitigation of project risk.

Project Manager Directs day-to-day activities of the project team.

Provides regular progress reports to the Steering Committee.

Delivering project plans, budgets, scoping and resourcing requirements and changes to the Steering Committee for approval.

Ensures effective delivery of the business process changes, including documentation and training.

Undertakes full risk assessments, and develops and implements risk mitigation strategies as agreed by the Steering Committee.

Provides full and proper quality assurance at regular intervals, and acting on the quality assurance findings, reports to the Sponsor as appropriate.

Manages all third parties contracted during the project life cycle.

Chris Neitzey, POD Inc.

Project Team / Stakeholders

Individuals identified here provide expertise in their designated area and report issues, concerns, and possible solutions to the Steering Committee. These individuals also communicate back to their departments.

Finance: Anna Arellanes TBD, Chief Financial Officer Customer Service: Kimberly Scott Public Outreach: Ramona Martinez IT: Valerie Krantz-Burge Jennifer Mills Executive Member: David Archuleta, Deputy Director Board Member: TBD

2.6 ROLES AND RESPONSIBILITIES OF THE POD TEAM

Roles Responsibilities Resources

Company Executive

Has responsibility for the overall performance of the contract.

King





Addresses team performance issues.

Principal Investigator (PI)

Owns technologies/approaches used for the project.

Works with RHCA to refine existing requirements and define any additional business and technical requirements for the project.

Atkinson

Project Manager Manages the contractual requirements.

Acts as direct liaison with the RHCA management.

Manages schedule/costs/budget/scope.

Manages deliverable dates and customer expectations as described in the contract.

Works with the technical lead, product owner, and company executive to remove impediments.

Conducts and records status meetings with RHCA management.

Provides coordination and logistics for the team as needed.

Neitzey

Product Owner Participates in initial Daily Sprint meetings.

Facilitates the Iteration meetings.

Creates the product vision.

Creates the product roadmap.

Creates and maintains the product backlog.

Plans releases and prioritizes Iteration activities.

Works with the PI to refine existing requirements and define any additional business and technical requirements for the project.

Addresses schedule issues with the development team and coordinates with the Project Manager.

King

Technical Lead Facilitates the Daily Sprint meetings.

Creates and maintains the sprint backlog.

Owns the process for project activities (sprints).

Supports the development team, product owner, and management team.

Works with the product owner or Project Manager to remove impediments.

Coaches the product owner and team by teaching and helping improve productivity, work practices, and tools.

Protects the team from interruptions or interferences during the sprint.

Finds techniques for effective product backlog management.

Provides release planning and prioritizes sprint activities.

Clearly communicates vision, goals, and product backlog items to the development team

Newquist

Development Participates in the Daily Sprint Meetings. Contreras (BizTalk)





Team Delivers product increments.

Utilizes sprint backlog and reports sprint progress.

Determines how to turn sprint backlog into increments for releasable functionality.

The whole team is accountable for the completion/success of the functionality.

Tritz (Architecture) Lucero (SharePoint) Schroeder (SharePoint) Buehler (SharePoint) McCashland (Database) TBD (Quality) Morrow (Training) Vosburg (Technical Writer) Harmon (Dev)

2.7 EXECUTIVE REPORTING

The contractor, POD Inc., will provide a formal written monthly project status report to the RHCA Project Director. This report is needed prior to the monthly meeting which occurs on the first Tuesday of the month. Therefore the status report is needed by the Friday prior to this date. The format shall be approved by the RHCA Project Director prior to issuance of the first (1st) status report. Much of the information is maintained weekly in the Project Cadence Workbook, and the high-level summary data is provided in the monthly status report. The chart below should help clarify how this reporting will be managed.

# Content Cadence Workbook Monthly Status Report

1 Overall completion status of the project in terms of the approved work plan and schedule

Information provided on a weekly basis as part of the weekly status with respect to the schedule reflected in MS Project 2010.

Will provide a snapshot view as a PDF report from MS Project, showing progress against the plan.

2

Updated project timeline showing percentage completed, high-level tasks assigned / completed / remaining, and milestone variance


Will provide a snapshot view as a PDF report from MS Project, showing progress against the plan.

3 Identification of schedule slippage and strategy for resolution


Will provide a section to address any schedule variances and strategy for resolution.

4 Milestones—upcoming, completed, and slipping.


A section will be added to the monthly status report to reflect current milestone activity.

5

Accomplishments for the reporting period and planned activities for the next reporting period

No narratives are provided in the Cadence Workbook.

The monthly status will include a section for monthly accomplishments and planned activities for the next month.




# Content Cadence Workbook Monthly Status Report

6 Problem/issue tracking

An Issues tab is maintained in the Cadence Workbook; the content will be reviewed as part of the regular status meetings.

A section will be included to report any issues requiring executive attention.

7 Quality Control / Testing (during development activities only)

Not maintained weekly

A section will be added to the monthly status report to reflect testing results during the iterations.

8 Identification of contractor staff working onsite at RHCA and their schedule

This matter can be addressed as part of the weekly cadence updates.

A section to address contractor personnel onsite and their proposed schedule for the upcoming month will be added.

9 Agency resources required for activities for the upcoming month.

A tab will be included in the Cadence Workbook to reflect RHCA resources’ required participation in upcoming activities; this information will be updated monthly.

Section included in the monthly status report to reflect Agency Resource Requirements projected for the upcoming month

10 Overall Project Health Not maintained weekly

Section will be added to the monthly status report to reflect dashboard status as reflected in the 7-keys maintained in the Cadence Workbook. This will include green, yellow, red status with supporting comments.

Below is the proposed template to use for reporting purposes.

REBIS Status Report Template.docx




2.8 PROJECT ESCALATION PATH

Escalation Path

Project Issue

Tiara Grant, RHCA Project Director

Tomas Rodriguez, RHCA Project Sponsor

Mark Tyndall, Executive Sponsor

Chris Neitzey, POD Project Manager

Jon King - Division Mgr (Resources)

Dale Atkinson - CIO (Technical / Client Relationship)

Samantha Lapin – CEO (Contract / Client Relationship)




3 SCOPE

3.1 PROJECT GOALS

Number Description

1. Improve first call resolution rates by increasing information and forms available to

Retirees on the RHCA web site.

2. Ensure continuous communication flow amongst all REBIS end-users.

3. Improve Retiree satisfaction with NMRHCA services

4. Improve billing and collections procedures and notifications and audit trails.

5. Provides actionable insight into the RHCA center activity by providing real time audit

trails and notifications.

6. Provide end-users with a web-based interface that will be designed to consistently

handle Member management for all end-users throughout all RHCA offices

7. Provide intuitive, comprehensive, and easy-to-use tools so CSRs can provide

superior service the Members.

8. Provide Supervisors and Directors with the information necessary to make real-time

decisions that improve customer satisfaction and improve RHCA performance.

3.2 PROJECT BUSINESS AND TECHNICAL OBJECTIVES

Number Description 1. Accurate Retiree Information – The system must provide accurate retiree

information that is submitted to its health care carriers by the NMRHCA. Accuracy will be measured by the number of retiree corrections reported by the health care partners to the NMRHCA.

2. Correct Retiree Pension Deductions – The system must correctly withdraw pension deductions from retiree pensions that pay for retiree health care benefits. Accurate pension deductions will be measured by the number of incorrect monthly pension deductions reported.

3. Executive Dashboard – The system will provide an executive dashboard to the executive staff that will accurately provide up-to-date information on retiree information such as the number of retirees per health plan as well as financial information such as accurately tracking employee payments. The objective will be measured by the accuracy of the data in the reports that are identified in the planning phase.

4. HIPAA Compliance - HIPAA applies to all “covered entities,” which the law defines




Number Description as health plan administrators, health information clearinghouses, and healthcare providers that transmit information electronically. The design of the REBIS system must address HIPAA regulations and NMRHCA must demonstrate that HIPAA has

been addressed through design documents and policy that help to prevent, detect security events and allow for the correction of HIPAA security violations.

5. IEEE Standards - To design a Retiree Benefit Intake System that is based on IEEE engineering standards for software engineering that will be measured through the code review process.

6. Business Requirements - To design a system that meets the business requirements of all divisions of the agency measured through the approved business cases.

7. Reliable and Efficient System - To design an efficient and reliable computer environment that supports the Retiree Benefit Intake System measured through the amount of system latency and system downtime.

8. HIPAA Compliance – The system will be responsible for the transmission of personal information; thus, files will be encrypted and comply with HIPAA rulings. Any new hardware, hardware firmware, software, operating systems and the application will be in compliance with HIPAA regulations.

3.3 CRITICAL SUCCESS FACTORS

Number Description Measure

1. Ensure 90% accuracy of

Retiree profile that can be

presented to CSR at the

start of a call or in-person

meeting, the more

successful the interaction

will be.

REBIS Edits Report is run every Friday to

review errors on Members profiles before

information is sent to providers. RHCA will

track the errors over the next 30 days under

the “Eligibility Errors REBIS” and the “Cobra

Edits”.

Formulas:

(EligibiltyErrors)+(CobraEdits)/total # Profiles=

Error % for the week

Error % for all 4 weeks/4=Avg. Error % over

30 days.

2. Improve call handle times by Call report will be run for Jan. 2012- Dec.




Number Description Measure

5%. 2012 from the current call center system to

determine a baseline for the number of

calls/month.

3. Reduce printing and postage

costs by 5% by improving

workflow at RHCA offices.

The baseline will be determined by the current

administrative operating costs (Jan. 2012-

Dec. 2012) for:

-Printing

-Postage

3.4 SCOPE MANAGEMENT PLAN

The Project Manager will follow a formal process for change control. The project team will maintain control of scope by establishing baselines where needed, define a change process with change log and written change form, define the approval process for project changes, and facilitate the formal change control process as part of ongoing activities.

3.4.1 CHANGE CONTROL

Contractor may only make changes or revisions within the Scope of Work as defined by Article 2 and Exhibit A of their contract after receipt of written approval by the Executive Level Representative (Project Sponsor). Such change may only be made to Tasks or Sub-Task as defined in the Exhibit A. Under no circumstance shall such change affect the:

Deliverable requirements, as outlined in Exhibit A;

Compensation of any Deliverable, as outlined in Exhibit A;

Agreement compensation, as outlined in Article 3; or

Agreement termination, as outlined in Article 5. The deliverable dates will be initially established as part of the approved and baselined schedule. An initial contract modification will be initiated to set these revised dates. Any future changes to these baselined dates would need to be approved by the Steering Committee and not required a contract modification.

3.4.1.1 Change Control Process

In the event that circumstances warrant a change to accomplish the Scope of Work as described in Section 3.3.1 Change Control, a change request shall be submitted that meets the following criteria:




1. The Project Manager shall draft a written change request for review and approval by the Executive Level Representative to include:

(a) the name of the person requesting the change;

(b) a summary of the required change;

(c) the start date for the change;

(d) the reason and necessity for change;

(e) the elements to be altered; and

(f) the impact of the change. 2. The Executive Level Representative shall provide a written decision on the

change request to the Contractor within a maximum of ten (10) business days of receipt of the change request. All decisions made by the Executive Level Representative are final. Change requests, once approved, become a part of the Agreement and become binding as a part of the original Agreement.

Change control will be managed by the Project Manager, with final approval by the RHCA designees. This will be managed according to the business and budgetary protocols and procedures of the Agency. This would include ensuring that the budget manager needs to have signoff on changes that affect the budget. The Project Change Request (PCR) Form template can be found in the project folder in SharePoint and is also attached here. The project Change Request Log will be maintained by the Project Manager.

Project Change Request Form.doc




4 DELIVERABLES / MILESTONES

4.1 DELIVERABLES

The target dates for the deliverables are referenced in Section 5.2, Work Breakdown Structure. In the table below are the key deliverables identified by type, along with the acceptance criteria. Standards for deliverables are identified once and apply to all deliverables in the table. Standards identified for Content and Format of Deliverables:

a. Deliverable narratives will use Microsoft Word, Excel, Visio, and Project (versions as specified by the NMRHCA) and the repository software will be MS SharePoint

b. All the deliverables will be given to the Project Director. c. All document deliverables will have a title page with a deliverable number and date. d. Document deliverables will have a table of contents. e. All document deliverables will have the title, version number, date, and page number on

each page. f. Document deliverables will be in electronic form. g. Information in document deliverables will be organized into logical sections/chapters.

h. Non‐software deliverables will have a cover memo dated or e-mail transmittal date in order to start the approval clock.

i. Each document deliverable will include an introduction identifying the deliverable. j. All deliverables will utilize consistent naming and terminology (standard naming

conventions), as defined in the project glossary.

# Deliverables Name Type Acceptance Criteria

1

Draft Initial

Requirements

Definition and

Design

Documentation

Document

Meet with designated Agency staff to verify and refine the existing requirements and add new requirements as needed.

Conduct Business Analysis and Joint Application Design Sessions with designated Agency staff to define the requirements.

Visio representation of current work flow is generated demonstrating what the user and the system follows.

High-level Requirements modified from previously provided information.

Document the results of the Business Analysis and Joint Application Design Sessions in draft initial high-level requirements and design documentation for Agency review and approval.

Submit the draft Initial Requirements Definition and Design Documentation to the Agency for review and approval of the draft documentation.





2

Final Initial

Requirements

Definition and

Design

Documentation

Document

Finalize Initial Requirements Definition and Design Documentation, based on Agency feedback

Submit the Final Initial Requirements Definition and Design Documentation to the Agency for review and approval of the final documentation

Iterative design improvements will occur throughout the Software Development Life Cycle.

3

Draft PMP,

Schedule and

Quality Plan

Document

Develop the Project Management Plan (PMP), project schedule, and Quality Plan, based on the information gained during the requirements definition activities carried out during the performance of Deliverables 1 and 2.

Submit the draft PMP, Schedule, and Quality Plan documentation to the Agency for review and approval of the draft documentation.

4

Final PMP,

Schedule and

Quality Plan

Document

Finalize the Project Management Plan (PMP), project schedule, and Quality Plan, based on Agency feedback.

Submit the Final Project Management Plan (PMP), project schedule, and Quality Plan Documentation to the Agency for review and approval of the final documentation.

5 Draft Test Plan Document

Work with Agency staff to develop the Draft Test Plan that defines the test plans to test the software to meet the approved requirements in Deliverable 2. The test scripts will be developed as part of the Iterations during each module development for those deliverables.

Submit the Draft Test Plan Documentation to the Agency for review and approval of the draft documentation.

6 Final Test Plan Document

Finalize the Test Plan based on Agency feedback.

Submit the Final Test Plan to the Agency for review and approval of the final documentation.


7 Draft Training Plan Document

Work with Agency staff to develop the Draft Training Plan for training and transferring knowledge to Agency staff in accordance with the approved requirements in Deliverable 2.

Submit the Draft Training Plan Documentation to the Agency for review and approval of the draft documentation.

8 Final Training Plan Document Finalize the Training Plan, based on Agency feedback.

Submit the Final Training Plan to the Agency for review and approval of the final documentation.





9

Draft Detailed

Requirements

Specification

Documentation

Document

In accordance with the approved requirements in Deliverable 2, work with Agency staff to develop the detailed requirements documentation.

Submit the Draft Detailed Requirements Documentation to the Agency for review and approval of the draft documentation.

10

Final Detailed

Requirements

Specification

Documentation

Document

Finalize the Detailed Requirements Specification Documentation, based on Agency feedback.

Submit the Final Detailed Requirements Documentation to the Agency for review and approval of the final documentation.


11

Draft Detailed

Design

Documentation

Document

In accordance with the approved requirements in Deliverable 2, work with Agency staff to develop the detailed requirements and design documentation.

User Stories have been developed to support the requirements

Other system functional details have been documented.

Submit the Draft Detailed Design Documentation to the Agency for review and approval of the draft documentation.

12

Final Detailed

Design

Documentation

Document

Finalize the Detailed Design Documentation, based on Agency feedback.

Submit the Final Detailed Design Documentation to the Agency for review and approval of the final documentation.


13

Draft REBIS

Software

Architecture

Functioning SW

In accordance with the approved detailed requirements and documentation in Deliverable 10 and 12, work with Agency staff to develop the draft software architecture, which includes the software framework, design, workflows, and layout.

The Deployment of the architecture to the RHCA servers will include:

o The software systems required to support REBIS (SQL Server 2012, BizTalk 2013, SharePoint 2013, and supporting Microsoft subsystems.

o the Initial REBIS internal and external websites

o Placeholders in the websites for the functionality defined in the requirements

Submit the Draft Software Architecture to the Agency for review and approval.





14

Final REBIS

Software

Architecture

Functioning SW

Finalize REBIS Software Architecture, based on Agency feedback.

Submit the Final REBIS Software Architecture to the Agency for final review and approval.


15 Draft REBIS

Database Design Document

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12, work with Agency staff to develop the draft database design based on the current REBIS database system and includes the design for the test system and auditing setup, database, development and implementation.

Submit the Draft Database Design to the Agency for review and approval.

16

Final REBIS

Database

Implementation

Functioning SW

Implement the REBIS Database based on the approved design in Deliverable 15.

Submit the REBIS Database to the Agency for final review and approval.


17

Final Nonfunctioning

Enroll Retiree Data

Entry Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop a nonfunctioning Enroll Retiree Data Entry Prototype that visually demonstrates the look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize the nonfunctioning Enroll Data Entry prototype.

Submit the Final Nonfunctioning Enroll Retiree Data Entry Prototype to the Agency for final review and approval.

18

Final Functioning

Enroll Retiree Data

Entry Software

Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12, the finalized software and database architectures in Deliverables 14 and 16, and the finalized prototype in Deliverable 17, work with Agency staff to develop the functioning Enroll Retiree Data Entry software module.

Iterate with Agency staff on the initial functioning software module to finalize the functioning Enroll Retiree Data Entry software module.

Submit the Final Functioning Enroll Retiree Data Entry software to the Agency for final review and approval.






19


Benefit Plan Data

Entry Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop a nonfunctioning Benefit Plan Data Entry Prototype that visually demonstrates the look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize the nonfunctioning Benefit Plan Data Entry prototype.

Submit the Final Nonfunctioning Benefit Plan Data Entry Prototype to the Agency for final review and approval.

20

Final Functioning

Benefit Plan Data

Entry Software

Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12, the finalized software and database architectures in Deliverables 14 and 16, and the finalized prototype in Deliverable 19, work with Agency staff to develop the functioning Benefit Plan Data Entry software module.

Iterate with Agency staff on the initial functioning software module to finalize functioning Benefit Plan Data Entry software module.

Submit the Final Functioning Benefit Plan Data Entry software to the Agency for final review and approval.


21


Executive

Dashboard

Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop a nonfunctioning Executive Dashboard Prototype that visually demonstrates the look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize the nonfunctioning Executive Dashboard prototype.

Submit the Final Nonfunctioning Executive Dashboard Prototype to the Agency for final review and approval.





22

Final Functioning

Executive

Dashboard Software

Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12, the finalized software and database architectures in Deliverables 14 and 16, and the finalized prototype in Deliverable 21, work with Agency staff to develop the functioning Executive Dashboard software module.

Iterate with Agency staff on the initial functioning software module to finalize functioning Executive Dashboard software module.

Submit the Final Functioning Executive Dashboard software to the Agency for final review and approval.


23


BizTalk 2012

Application

Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop a nonfunctioning BizTalk 2012 Application Prototype that visually demonstrates the look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize the nonfunctioning BizTalk 2012 Application prototype.

Submit the Final BizTalk 2012 Application Prototype to the Agency for final review and approval.

24

Final Functioning

BizTalk 2012

Application Software

Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, and the finalized prototype in Deliverable 23, work with Agency staff to develop the functioning BizTalk 2012 Application software module.

Iterate with Agency staff on the initial functioning software module to finalize a functioning BizTalk 2012 Application software module.

Submit the Final Functioning BizTalk 2012 Application software to the Agency for final review and approval.






25


Reports including

Letters and Forms

Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop nonfunctioning Reports, including a Letters and Forms Prototype that visually demonstrates the look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize nonfunctioning Reports including Letters and Forms prototype.

Submit the Final Nonfunctioning Reports including Letters and Forms Prototype to the Agency for final review and approval.

26

Final Functioning

Reports including

Letters and Forms

Software Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12, the finalized software and database architectures in Deliverables 14 and 16, and the finalized prototype in Deliverable 25, work with Agency staff to develop the functioning Reports including Letters and Forms software module.

Iterate with Agency staff on the initial functioning software module to finalize functioning Reports including Letters and Forms software module.

Submit the Final Functioning Reports including Letters and Forms software to the Agency for final review and approval.


27


Payment System

Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop a nonfunctioning Payment System Prototype that visually demonstrates the software look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize nonfunctioning Payment System prototype.

Submit the Final Nonfunctioning Payment System Prototype to the Agency for final review and approval.





28

Final Functioning

Payment System

Software Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, and the finalized prototype in Deliverable 27, work with Agency staff to develop the functioning Payment System software module.

Iterate with Agency staff on the initial functioning software module to finalize functioning Payment System software module.

Submit the Final Functioning Payment System software to the Agency for final review and approval.


29


Admin System

Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop a nonfunctioning Admin System Prototype that visually demonstrates the software look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize nonfunctioning Admin System prototype.

Submit the Final Nonfunctioning Admin System Prototype to the Agency for final review and approval.

30

Final Functioning

Admin System

Software Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 12 and 14, and the finalized prototype in Deliverable 29, work with Agency staff to develop the functioning Admin System software module.

Iterate with Agency staff on the initial functioning software module to finalize functioning Admin System software module.

Submit the Final Functioning Admin System software to the Agency for final review and approval.






31


Retiree Web Data

Entry Interface

Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop a nonfunctioning Retiree Web Data Entry Interface Prototype that visually demonstrates the software look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize nonfunctioning Retiree Web Data Entry Interface prototype.

Submit the Final Nonfunctioning Retiree Web Data Entry Interface Prototype to the Agency for final review and approval.

32

Final Functioning

Retiree Web Data

Entry Interface

Software Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, and the finalized prototype in Deliverable 31, work with Agency staff to develop the functioning Retiree Web Data Entry Interface software module.

Iterate with Agency staff on the initial functioning software module to finalize functioning Retiree Web Data Entry Interface software module.

Submit the Final Functioning Retiree Web Data Entry Interface software to the Agency for final review and approval.


33


New Image Input

and Storage

Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, work with Agency staff to develop a nonfunctioning New Image Input and Storage Prototype that visually demonstrates the software look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize nonfunctioning New Image Input and Storage prototype.

Submit the Final Nonfunctioning New Image Input and Storage Prototype to the Agency for final review and approval.





34

Final Functioning

New Image Input

and Storage

Software Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, and the finalized prototype in Deliverable 33, work with Agency staff to develop the functioning New Image Input and Storage Interface software module.

Iterate with Agency staff on the initial functioning software module to finalize functioning New Image Input and Storage software module.

Submit the Final Functioning New Image Input and Storage software to the Agency for final review and approval.


35 Database Data

Migration Design Document

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16 work with Agency staff to design the database migration to move the legacy data from the current REBIS system to the new REBIS Upgrade and Enhancement project system.

Iterate with Agency staff on the Database Data Migration Design.

Submit the Final Database Data Migration Design to the Agency for review and approval.

36 Database Data

Migration Functioning

SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12, the finalized software and database architectures in Deliverables 14 and 16 and design in Deliverable 35, work with Agency staff to move the legacy data from the current REBIS system to the new REBIS Upgrade and Enhancement project system.

Iterate with Agency staff on the Database Data Migration

Submit the Final Database Data Migration to the Agency for review, testing, acceptance and approval.






37 Database Image

Migration Design Document

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16 work with Agency staff to design the database migration to move the legacy images from the current REBIS system to the new REBIS Upgrade and Enhancement project system.

Iterate with Agency staff on the Database Image Migration Design

Submit the Final Database Image Migration Design to the Agency for review and approval.

38 Database Image

Migration Functioning

SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16 and design in Deliverable 37, work with Agency staff to move the legacy images from the current REBIS system to the new REBIS Upgrade and Enhancement project system.

Iterate with Agency staff on the Database Image Migration

Submit the Final Database Image Migration to the Agency for review, testing, acceptance and approval.


39 Operational Plan Document

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16 work with Agency staff to develop the draft Operational Plan that documents how NMRHCA staff will operate utilizing the REBIS Upgrade and Enhancement project system.

Submit the draft Operational Plan to the Agency for comments and review.

Based on the feedback received from Agency staff on the draft Operational Plan, modify the Plan.

Submit the Final Operational Plan to the Agency for review and final approval.





40


Online Help System

Prototype

Prototype

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software, database architectures in Deliverables 14 and 16, and finalized software modules, work with Agency staff to develop a nonfunctioning Online Help System Prototype that visually demonstrates the software look and feel and functionality of this software module.

Iterate with Agency staff on the initial nonfunctioning prototype to finalize nonfunctioning Online Help System prototype.

Submit the Final Online Help System Prototype to the Agency for final review and approval.

41

Final Functioning

Online Help System

Software Module

Functioning SW

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12, the finalized software and database architectures in Deliverables 14 and 16, and the finalized software modules, work with Agency staff to develop the functioning Online Help System software module.

Iterate with Agency staff on the initial functioning software module to finalize functioning Online Help System software module.

Submit the Final Functioning Online Help System software to the Agency for final review and approval.


42 User Integration

Test Signoff Document

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 and the finalized software and database architectures in Deliverables 14 and 16, the finalized software modules, and test criteria, work with Agency staff to conduct the user functional acceptance test signoff to ensure that all modules are functioning correctly.

Submit the sign off sheet to the Agency for final approval.

43 User Acceptance

Test Signoff Document

In accordance with the approved detailed requirements and design documentation in Deliverable 10 and 12 the finalized software and database architectures in Deliverables 14 and 16, the finalized software modules, and test criteria, work with Agency staff to conduct the user functional acceptance test signoff to ensure that entire REBIS Upgrade and Enhancement software system is functioning correctly.

Submit the sign off sheet to the Agency for final approval.





44 User Documentation Document

In accordance with the final accepted REBIS Upgrade and Enhancement project system in Deliverable 43, develop the user guide, user documentation.

Submit the draft User Documentation (Guide) to the Agency for comments and review.

Based on the feedback received from Agency staff on the draft User Documentation, modify the Documentation.

Submit the Final User Documentation to the Agency for review and final approval.

45 Technical

Documentation Document

In accordance with the final accepted REBIS Upgrade and Enhancement project system in Deliverable 43, develop the technical documentation.

Submit the draft Technical Documentation (Guide) to the Agency for comments and review.

Based on the feedback received from Agency staff on the draft Technical Documentation, modify the Documentation

Submit the Final Technical Documentation to the Agency for review and final approval.

46 End User Training Training Delivery

In accordance with the final accepted REBIS Upgrade and Enhancement project system in Deliverable 43 and related documentation in Deliverable 44, develop the in-person end user training.

Submit the draft End User Training materials to the Agency for comment and review.

Modify the End User Training materials based on Agency feedback.

Submit the Final End User Training materials to the Agency for review and final approval.

Conduct the in-person End User Training based on the approved final materials and submit the End User Training Signoff sheet to the Agency for final approval.

47 Technical Training Training Delivery

In accordance with the final accepted REBIS Upgrade and Enhancement project system in Deliverable 43 and related documentation in Deliverable 44, develop the technical training.

Submit the draft Technical Training materials to the Agency for comment and review.

Modify the Technical Training materials based on Agency feedback.

Submit the Final Technical Training materials to the Agency for review and final approval.

Conduct the in-person Technical Training based on the approved final materials and submit the Technical Training Signoff sheet to the Agency for final approval.




4.2 MILESTONES

Listed below are the key milestones for this project along with their target dates.




4.3 DELIVERABLE APPROVAL AND ACCEPTANCE

This section is not intended to replace what is stated in the contract, but to provide further clarification on how this process will work for this project. The contract states that invoices will be submitted per individual deliverables. As stated in the contract, the Executive Director or designee shall determine if the Deliverable provided meets specifications. No payment shall be made for any Deliverable until the individual Deliverable that is the subject of the Payment Invoice has been accepted, in writing, by the Executive Director or designee. In order to accept the deliverable, the Executive Director or designee, in conjunction with the Project Sponsor, will assess the Quality level of the Deliverable and determine, at a minimum, that the Deliverable:

Complies with the Deliverable requirements as defined in the contract.

Complies with the terms and conditions of the RFP#30-343-00-00442.

Meets the performance measures for the Deliverable(s). Acceptance Signoff Form (ASF) Procedure All deliverables will require an Acceptance Signoff Form that will be delivered along with any associated artifacts for the deliverable types.

All contractor deliverables will be approved by the RHCA Project Sponsor.

For draft deliverables, the customer will have 5 business days to review and provide feedback to the contractor team.

The RHCA Project Sponsor will have 5 business days for final approvals.

The ASF will be sent via e-mail to both the RHCA Project Sponsor and the RHCA Project Director along with a link to the associated deliverable stored in the Project Repository or the location of the source code.

Signed copy of the ASF will be made available to the POD Project Manager either hard copy or scanned. The POD Project Manager will post this approval in the Project Repository.

The POD Project Manager will ensure that the invoice includes the appropriate signed ASF.

Deliverable Type Deliverable Method

Document Copy of the deliverable will be posted in the External Project Repository (Connect site). An e-mail will be sent to the RHCA Project Director and the RHCA Project Sponsor advising that this has been done along with the ASF. See ASF procedure identified above.

Training Delivery A report of all attendees and modules completed will be provided. E-mail will be sent to the RHCA Project Director with this information




and the ASF within two days after each training phase has been completed. See ASF procedure identified above.

Non-Functioning Prototypes

As part of the Scrum process, the customer team will be present during the final demonstration of the non-functioning prototype. Information would be stored as part of Team Foundation Server (TFS). See ASF procedure identified above.

Functioning Software Module

As part of the Scrum process, the customer team will be present during the final demonstration of the functionality as defined in the Iteration Planning. Upon demonstration of the functionality, the source code will be provided to RHCA on their designated server. A three-week period will be established for the RHCA team to perform independent testing prior to signoff for the deliverable. RHCA will provide feedback on the results of their testing. Detailed results of the testing will be provided along with the ASF. See ASF procedure identified above.




5 PROJECT WORK

5.1 APPROACH

POD Software Development Life Cycle

Requirements Gathering JAD Sessions w/High level Design Business Use Case Design Requirements Traceability Matrix

Project Planning Activities Schedule / PMP Quality Plan Test Plan Training Plan

Project Definition

Software Development Iterations

Project Execution

Iteration 1

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Iteration nnn

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Testing~~ System Integration Testing~~ User Acceptance Testing

User Documentation~~ User Guide~~ Technical Guide

Training~~ Develop Training Materials~~ Conduct Training

Project Rollout – GO Live

Documentation~~ Requirements~~ Design

Warranty Period

Sprint Task List

Sprint

Daily MeetingsNew functionality demonstrated

Functionality to be developed through Sprints

Project Plan in MicroSoft Project

(includes comprehensive task

list)

Reprioritize (prepare for next sprint)

Iteration nnn

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Operations Definition~~ Operational Plan

Initial Non-functioning Prototype

Final Non-functioning Prototype

Initial Functioning

Software Module

Final Functioning

Software Module




The iterative phases of the project, depicted in Figure above and managed by POD’s Project

Manager, are as follows:

Phase Summary of Phase Key Outputs

Project Definition

Planning Activities include not only the fine-tuning of the project schedule and the development of a detailed project management plan but also the development of the project’s quality plan, the test plan, and the training plan for the project. All these plans should be written at the beginning of the project, but refinements to these plans may be made during the software development iterations/sprints as needed. In particular, even though the overall test plan may be developed, the specific scripts that will be utilized during system integration testing and user acceptance testing will be developed as part of the development process.

JAD Sessions

High-level Design

Business Use Case Design

Detailed Project Schedule and Project Manage-ment Plan

Test Plan

Training Plan

Project Documentation

The draft documentation that was initiated during the JAD sessions and part of requirements definition will be finalized as the first step of Project Execution. The requirements and design documentation will be the key focal points as the team works through the sprint cycles. It is expected that as part of the sprint cycles, changes and refinements may be made to these documents and will be validated with the NMRHCA SMEs assigned to work with the POD team. It is assumed that NMRHCA team will work closely with the POD team to ensure a quick turnaround for review and approvals for this documentation.

Project requirements document

Project design document

Software Development

Thirty (30) two-week sprint cycles will occur during the entire development process. These sprint cycles have been grouped into software iterations that will focus on key functional areas as defined during the JAD sessions. Each of the iterations will normally consist of four (4) sprint cycles, with the exception of the last one, which will consist of five. The first two iterations will deal with the software architectural framework and the database design and implementation. The last one will focus on finalizing all the functionality that has been addressed in previous iterations and address any changes and fine-tuning needed as a result of the feedback provided throughout the process.

Software development iterations defined in sprints.

Operations Definition

A plan for the overall business operations will be defined. Operational Plan

Testing All unit-testing will be conducted during these iterations, with scripting identified for both integration and user acceptance testing. The initial test plan developed for the project will provide the details around how the testing will be conducted and approved and how changes will be addressed. At the end of the iterations, the actual integration testing and user acceptance testing will be performed.

System Integration Testing

User Acceptance Testing




Phase Summary of Phase Key Outputs

User Documentation

There are two forms of user documentation that are targeted for this effort: User Guide and Technical Guide. Both of these documents will follow the normal approval process of developing a draft and performing internal quality reviews prior to submission to NMRHCA for review and feedback. Time has been allocated for the customer review, and then time to incorporate these comments before submitting the documents as final. Both of these documents will be utilized as part of the user training.

User Guide

Technical Guide

Training In addition to the user documentation, training materials will be developed to facilitate the instruction period. The approval of these materials will follow the same approach as defined above for User Documentation. There will be two training activities performed: End-user and IT Staff Training. The training plan will identify in more detail how this will be conducted. Training will be scheduled in advance so that all anticipated recipients can make room in their schedules to attend.

Development of Training Materials

Conduct Training

Project Rollout After all the training has been conducted and signoffs have been received for the testing activities on the software, a cutover process will be implemented for the application to go live.

Go live

Closeout Phase and Customer Survey

Internal project closeout activities will be conducted after GO LIVE, with final closeout occurring after the warranty period is completed. One important aspect of project closeout is conducting and documenting the lessons learned.

Lessons learned

Ongoing Maintenance and Support

There is a six-month no-cost warranty period built into the project plan. This period allows the POD team, within the time periods identified in the plan, to fix any bugs identified after the software goes into production. For the purpose of the warranty period, bugs are defined as software errors. Bugs do not include functional changes or screen changes to the software (e.g., cosmetic changes, such as changing the workflow or moving a button on a screen).

Six-Month Warranty Period

POD’s Sprints Incorporating aspects of ScrumTM into the AgileTM approach, the project team executes a series of iterative sprints; these sprints will implement incremental functionality defined by subsets of the project task list as shown in the table above. The project is closely monitored through highly focused daily status meetings. At the end of each sprint, the backlogged features for the entire design are reprioritized, based on the results of the sprint. At the end of a set number of sprints, a delivered version of the product will be tested and reviewed with the client to provide for user acceptance of those particular features.




Customer Review

Iteration nnn

Sprint 1 Sprint

2 Sprint 3 Sprint

4

Requirements

Sprint Planning2 week Sprints with Daily

meetingsSprint Review

SprintRetrospective

Sprint / Iteration Backlog

Sprint Backlog

Grooming Non-Functioning

Prototype Functioning

Software Module

REBIS Scrum/Agile Approach

Product Backlog

Sprint

Iteration

Initial Non-functioning Prototype

Final Non-functioning Prototype

Initial Functioning

Software Module

Final Functioning

Software Module

Iteration Planning Iteration Review

Customer Participates

Updated Nov 21, 2012

Agile Activity Time Purpose PO TL DT PM C

Sprint Backlog Grooming undefined Clarification/refinements on User Stories/Tasks P P

Sprint Planning 4 hours Set up Sprint goals and select subset of Product Backlog P L P

Iteration Planning 4 hours Set up Iteration goals and select subset of Product Backlog L P P ? P

Daily Meetings 15 min What's Done, What's Planned, any impediments O L P

Sprint Review 2 hours Demo of accomplishments P P P L O

Iteration Review 2 hours Demo of functioning sw module L P P P P

Sprint Retrospective 1.5 hours Review of process and identify changes P L P P O

Customer Review 1-2 hours Review output of the sprint to obtain buy-in on output of Sprint L P P P

Role Involvement

Product Owner

Team Lead

Development Team

Project Manager

Customer

Leads, Participates, Optional




5.2 PRODUCT ROAD MAP

7/22/2013 8/1/2014

8/1/2013 9/1/2013 10/1/2013 11/1/2013 12/1/2013 1/1/2014 2/1/2014 3/1/2014 4/1/2014 5/1/2014 6/1/2014 7/1/2014

REBIS Product Roadmap

8/1/2014

Final Edits/Integration/Delivery

7/10/2014

Executive Dashboard

Reports and Letters

Retiree Web Data Entry Interface

Online Help

9/13/2013

Admin/Maintenance Module

External Website

1/9/2014

Employer Data Entry

Payment Module

Payment Data Migration

Image Storage/Retrieval

5/1/2014

External Vendor Data Access

BizTalk 2013 Module

BizTalk Data Migration

3/6/2014

Enroll Retiree Data Entry

Benefit Plan Data Entry

Retiree/Benefit Data Migration




5.3 WORK BREAKDOWN STRUCTURE




5.4 SCHEDULE

The project schedule is maintained by the POD Project Manager on the internal SharePoint site. For sharing purposes, a PDF version of the schedule will be provided to RHCA Management on the Connect (External) SharePoint site. A link to this location is referenced below. Once this initial schedule is approved it will be baselined and progress will be tracked against the approved baseline. https://connect.podassoc.com/REBIS/Shared Documents/02 Plans/Schedule

5.5 PROJECT TIMELINE VIEW

13/14 Software Architecture15 Database Design16 Database Implementation

12/10/2012 9/24/2014

1/13 2/13 3/13 4/13 5/13 6/13 7/13 8/13 9/13 10/13 11/13 12/13 1/14 2/14 3/14 4/14 5/14 6/14 7/14 8/14 9/14

12/10

Project Start

5/1

Initial Requirements /

Design Complete

5/6

Test Plan Complete

6/6Training Plan

Complete

7/3

Detailed Design Complete

8/19/13 - 8/1/14

SW Module Development Activities Completing

3/27Planning Complete

1/11

Kickoff Meeting

1/24 - 3/1

JAD Sessions

9/14

GO LIVE

6 month Warranty 9/25/2014 – 3/25/2015

REBIS Upgrade Project Timeline

Updated: 3/18/2013

9/19

Training Complete

Product Roadmapdefines incremental

development and rollout of REBIS

components

Functional Areas addressed in Product Roadmap:17/18 Enroll Retiree Data Entry 19/20 Benefit Plan Data Entry 21/22 Executive Dashboard23/24 BizTalk 2012 Application25/26 Reports (Letters/Forms)27/28 Payment System29/30 Admin System31/32 Retiree Web Data Entry Interface33/34 New Image Input and Storage35 Database Data Migration Design36 Database Data Migration37 Database Image Migration Design38 Database Image Migration40/41 Online Help System

39 Operations Plan42 User Integration Test Signoff43 User Acceptance Test Signoff

9/12Operations

Plan Complete

44 User Documentation45 Technical Documentation46 End User Training47 Technical Training

2/4 - 8/5

Architecture / Database Development

2/4Development

Sprints Begin

8/15User Integration

Test Signoff

8/29User Acceptance

Test Signoff

5/29

Requirements Specification

Complete

9/13

R1

11/8

R2

1/10

R3

4/4

R4

7/11

R5

8/1

R6

https://connect.podassoc.com/REBIS/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2fREBIS%2fShared%20Documents%2f02%20Plans%2fSchedule&FolderCTID=&View=%7bCA92D06A%2d3131%2d443A%2dA01C%2d80F3D3855BF4%7d




5.6 PROJECT BUDGET

The table below shows the contract deliverables for the software development effort by POD, Inc.

Del # Deliverables Name Amount

1 Draft Initial Requirements Definition and Design Documentation $ 43,560.00

2 Final Initial Requirements Definition and Design Documentation $ 10,890.00

3 Draft PMP, Schedule and Quality Plan $ 12,320.00

4 Final PMP, Schedule and Quality Plan $ 3,080.00

5 Draft Test Plan $ 5,280.00

6 Final Test Plan $ 1,320.00

7 Draft Training Plan $ 4,928.00

8 Final Training Plan $ 1,232.00

9 Draft Detailed Requirements Specification Documentation $ 15,180.00

10 Final Detailed Requirements Specification Documentation $ 3,795.00

11 Draft Detailed Design Documentation $ 15,180.00

12 Final Detailed Design Documentation $ 3,795.00

13 Draft REBIS Software Architecture $ 52,536.00

14 Final REBIS Software Architecture $ 13,134.00

15 Draft REBIS Database Design $ 71,522.00

16 Final REBIS Database Implementation $ 17,880.50

17 Final Nonfunctioning Enroll Retiree Data Entry Prototype $ 18,744.00

18 Final Functioning Enroll Retiree Data Entry Software Module $ 28,116.00

19 Final Nonfunctioning Benefit Plan Data Entry Prototype $ 13,464.00

20 Final Functioning Benefit Plan Data Entry Software Module $ 20,196.00

21 Final Nonfunctioning Executive Dashboard Prototype $ 18,480.00

22 Final Functioning Executive Dashboard Software Module $ 27,720.00

23 Final Nonfunctioning BizTalk 2012 Application Prototype $ 18,480.00

24 Final Functioning BizTalk 2012 Application Software Module $ 27,720.00

25 Final Nonfunctioning Reports including Letters and Forms Prototype $ 71,280.00

26 Final Functioning Reports including Letters and Forms Software Module $ 106,920.00

27 Final Nonfunctioning Payment System Prototype $ 29,040.00

28 Final Functioning Payment System Software Module $ 43,560.00

29 Final Nonfunctioning Admin System Prototype $ 17,160.00

30 Final Functioning Admin System Software Module $ 25,740.00

31 Final Nonfunctioning Retiree Web Data Entry Interface Prototype $ 18,216.00

32 Final Functioning Retiree Web Data Entry Interface Software Module $ 27,324.00

33 Final Nonfunctioning New Image Input and Storage Prototype $ 18,216.00

34 Final Functioning New Image Input and Storage Software Module $ 27,324.00




Del # Deliverables Name Amount

35 Database Data Migration Design $ 23,925.00

36 Database Data Migration $ 71,775.00

37 Database Image Migration Design $ 27,225.00

38 Database Image Migration $ 81,675.00

39 Operational Plan $ 23,100.00

40 Final Nonfunctioning Online Help System Prototype $ 11,220.00

41 Final Functioning Online Help System Software Module $ 16,830.00

42 User Integration Test Signoff $ 198,000.00

43 User Acceptance Test Signoff 15% Retainage

44 User Documentation $ 26,400.00

45 Technical Documentation $ 23,100.00

46 End User Training $ 19,800.00

47 Technical Training $ 16,500.00

Total $ 1,372,882.50

5.7 PROJECT TEAM

A complete project contact list is created and maintained in the Project Cadence Workbook and stored in the project repository. A snapshot of the key information is contained here for initial reference. As updates occur during the project, the contact list will be updated in the project cadence workbook

ORG NAME E-MAIL ADDRESS MAIN RESPONSIBILITY

RHCA Anna Arellanes [email protected] Finance

POD Brad Schroeder [email protected] SharePoint

POD Brad Tritz [email protected] Architect

POD Chris Neitzey [email protected] Project PM

POD Dale Atkinson [email protected] Principal Investigator

POD Dante Fernandez [email protected] Developer

RHCA Deb Whitmore [email protected] Finance

mailto:[email protected]











RHCA Gail Tanuz [email protected] Finance

RHCA TBD HR Director

RHCA Jason Ballard [email protected]

Customer Service / Project Tester

POD Jean Vosburg [email protected] Technical Writing

RHCA Jennifer Mills [email protected] Information Systems

POD Jim Harmon [email protected] Developer

POD Joan Morrow [email protected] Training

POD Jon King [email protected] Executive POC

POD Ken Davis [email protected] Developer

RHCA Kimberly Scott [email protected]

Customer Service Director

POD Liz Contreras [email protected] BizTalk

RHCA Mark Tyndall [email protected] Executive Director

RHCA Melissa Larrañaga [email protected] Customer Service

POD Mikael Newquist [email protected]

POD Technical Team Lead

POD Nathan Davis [email protected] Developer

RHCA Ramona Martinez [email protected] Public Outreach

POD Shanie Lucero [email protected] SharePoint

RHCA Shellie Miyaji-Garcia

[email protected]

Customer Service / Project Tester






















RHCA TBD Financial Specialist

RHCA TBD Chief Financial Officer

POD Laura Beltemacchi [email protected] Quality

RHCA David Archuleta [email protected] Deputy Director

RHCA TBD Board Member

POD Thomas Philbrick [email protected] Developer

RHCA Tiara Grant [email protected] Project Director

RHCA Tomas Rodriguez [email protected]

RHCA Project Sponsor and Primary POC / Steering Committee Chair

RHCA Valerie Krantz-Burge

[email protected]

Information Systems / Systems Analyst

POD Wayne McCashland

[email protected] Database











6 COMMUNICATION PLAN

Communication lines for the project need to be open, and ad hoc updates need to be provided for quick response. Listed below are some of the key communications that have been agreed to by the team. Further details are provided in the Project Cadence Workbook maintained in the project repository.

Meeting Title Est Time

Minutes Content Owner

Attendees Frequency

Internal Project Team Meetings

1 hr

POD Project PM

POD Internal Team

Periodic

Scrum Meetings during iterations

.25 hr

Team Lead Team Lead, Development

Team, Daily

RHCA Project Status Meetings

1 hr y POD Project

PM

RHCA Project Sponsor, RHCA Project Director, Product Owner,

POD Project Manager

Biweekly or more

frequently as needed

Sprint Customer Review

1-2 hrs

Product Owner

Technical Lead, POD Project

Manager, Project Director

Customer Representatives

As needed during sprints

Iteration Customer Review

2 hrs

Product Owner

Technical Lead, POD Project

Manager, Project Director,

Customer Representatives

At the end of each iteration

Steering Committee 1 hr y POD Project

PM Project

Oversight Team Periodic (QTRLY)

Weekly Updated Project Cadence Worksheet

Project PM

Entire Project Team

Weekly

Monthly Status Reports

Project PM Project Sponsor Monthly




7 DOCUMENT CONTROLS

All project documents will be stored in an internal SharePoint site, referred to as the Project Repository, set up and maintained by the POD Staff. The POD Project Manager will be the primary controller of the SharePoint sites and will provide guidance on requirements and access controls. Section 7.1 contains a graphic of how the documents will be managed and controlled within the POD environment. A common repository will be established for sharing of files between POD and the customer in an external SharePoint site. Access permissions for the external SharePoint site are reflected in the team chart tab maintained in the Cadence Workbook. Listed below are the links to the SharePoint sites: External site: https://connect.podassoc.com/REBIS/default.aspx Internal site: https://portal.poddatasolutions.com/PROJECTS/IT/REBIS/SitePages/Home.aspx

7.1 DOCUMENT MANAGEMENT

The project documentation follows the POD document management process as shown in the figure below. Internal working files are stored on a network share and in Microsoft OneNote. Internal working files and developer notes (including Microsoft OneNote files) are not subject to the constraints and change control processes defined in this PMP. Internal working files are used to produce project documents that are stored in the internal SharePoint site. When documents are finalized, the documents are moved to the external SharePoint site for distribution. The finalized documents are converted to PDF format before being placed on the external SharePoint site. This adds the responsibility for managing this document pair (Word document source and PDF delivered document) so that a future change requested in the PDF document will be made to the appropriate Word document source. All documentation that is produced for the RHCA REBIS project should follow the naming scheme below.

Internal working documents will follow:

DocumentName (unique identifier as needed).doc

Example(s): Biweekly Status Report 20110415.doc Configuration Management Plan.doc Semiannual Technical Progress Report 2.doc SharePoint maintains the version #, the editor name; the last edited date and edited comments. This information should align with what is in the version history of the document.

https://connect.podassoc.com/REBIS/default.aspx

https://portal.poddatasolutions.com/PROJECTS/IT/REBIS/SitePages/Home.aspx




Delivered documents will follow the following

DocumentName yyyymmdd v# DRAFT/FINAL.Doc where the Draft designation is used for a delivered draft document and the Final designation is used for a delivered final document. The date should be the official delivery date of the document and the version # should match what is stated in SharePoint.

Example: BiWeekly Status Report 20110415 v1.0 FINAL.doc

Documents that are directly associated with the project configuration baseline will be identified with a naming scheme consisting of the module name and date (i.e., <projectname>_DEV_<module>_<yyyymmdd>_<hhmm>). Documentation of release baselines will be identified with an incremental product number (i.e., <projectname>_<product.major.minor.patch>). All finalized documents will be stored and maintained in POD’s DocuShare document management system. At project completion, the project document artifacts from the network share, OneNote, and SharePoint sites will be archived.

ONE NOTE

Developer Working Area

Technical Documents

Quick Notes and

Collaborative Environment

Pointer to Files

Team Foundation Server (TFS) - Source Code

RAW Project Working

L:Project/Projects

Raw Working Documents:

Individual Specific

Internal SHAREPOINT

PORTAL.respec.com

Internal Files to Share with

team members

Source of Record

Active Project Artifacts

External SHAREPOINT

CONNECT.podassoc.com

Customer Shared Project

Repository includes:

Deliverables

Status reports

Meeting Minutes

Collaborative between POD

and Customer

Final Project Repository

DocuSHARE.podassoc.com

Deliverables; Status Reports;

Contracts; Invoices; Project

Closeout; Project Startup;

Financial Tracking;

Schedules; Minutes; Cadence

Workbook

POD Standards/Templates

Internal Working Files FINAL Documents

File format more formalized – see belowFree format File Structure

Primary Developer

Areas

Primary PM Areas

At Project Close – these

files are removed.

00. Project Specific

Standard_Templates

Contains customized templates such as

meeting minutes, report formats,

customized deliverable templates, etc.

01. Client Organizational Information

Contains logos, organizational charts,

contracts, agreements, contact lists etc.

02. Plans and Actuals

Contains PMPs, Schedules, Financial

information, Tracking spreadsheets,

Cadence Workbook, Project Setup

Worksheets, project close reports; project

closeout checklists; lessons learned;

customer satisfaction survey information

03. Communications

Contains Status Reports (internal/external),

Meeting Minutes, important emails

04. Quality

Contains quality reports, quality

worksheets, testing results or testing

signoffs

05. Deliverables

Contains all deliverables for the project and

record of approvals.

06. Artifacts

Contains any project background materials

provided by the customer as information

that is used as input for deliverables. This

information may not be retained at the

time of project close

Page 1

IT Information / Document Management Process, Flow and Structure

Updated 05/24/2012 v6

Collaborative

As Delivered & At Final Close

At Final Close

To Share w/Team




7.2 PROJECT CADENCE WORKBOOK

The Project Cadence Workbook is an integral component of the Project Management Plan (PMP). The PMP is the overall plan for how the project will be run and the workbook represents a series of associated worksheets that help to manage and track the work that is performed on the project from week to week. Elements of the workbook include an overall timeline for the project, Action Items, Issues Log, Risk Management Log, Change Log, Communications Plan, Meeting Log, Project Key Decisions, Deliverables, Team Organization/Governance, Project Contact List, Escalation Path and ongoing area to capture Lessons Learned as they occur. This becomes a valuable tool for communication between the Project Manager and the client’s management team and other interested parties on the current status of the project at any given time. All current information is maintained in one file and not only provides a single source file for utilization for project meetings, but it also useful for project status reports and provides a summary of the project at project close.

WBS / Deliverables

Scope Items – Actions;

Risks; Issues; Change;

Escalation Path

Project Success

Factors

Parking Lot


(PMP)

Project Cadence

Workbook

PMP is the narrative of the plan that is

utilized to explain the basis of HOW

the project will be managed.

Information from both Cadence,

Schedule and Financials are

incorporated initially into the PMP

Cadence workbook is an Excel

workbook with multiple tabs containing

information necessary for the DAY TO

DAY MANAGEMENT of the project.

Data is created in the workbook and

then transferred to the PMP for initial

planning purposes.

Communication –

Comm Plan, Meeting

Log; lessons Learned;

Key Decisions

Organization – Org

Charts; Team Contact

Lists

Schedule /

Financials

Separate files are used to

maintain the financials

and schedule for the DAY

TO DAY MANAGEMENT

of the project.

Page 1

Project Management Plan vs Project Cadence Workbook

Updated 12/03/3010 v1

Reporting

Status Reporting is

generated from the data

maintained in the

Cadence Workbook,

Schedule and Financials.




8 ACRONYMS

Acronym Description

ASF Acceptance Signoff Form

CEO Chief Executive Officer

CIO Chief Information Officer

HIPAA Health Insurance Portability and Accountability Act

HR Human Resources

IEEE Institute of Electrical and Electronics Engineers

IT Information Technology

JAD Joint Application Development

MS Microsoft

NMRHCA New Mexico Retiree Health Care Authority

PCC Project Control Certification

PCR Project Change Request

PI Principal Investigator

PM Project Manager

PMP Project Management Plan

POC Point of Contact

POD POD, Inc., Contractor

REBIS Retiree Eligibility Benefit Intake System

RHCA Retiree Health Care Authority

SDLC Software Development Life Cycle

SME Subject Matter Expert

SW Software

TBD To be determined

TFS Team Foundation Server

WBS Work Breakdown Structure




9 APPENDIX

EXHIBIT B – DELIVERABLE SUBMISSION AND REVIEW PROCESS The following Deliverable review process is subject to Section 4 of the Contract. Pursuant to such section of the Contract, all Deliverable reviews are for the purpose of determining whether each such Deliverable substantially meets Contract specifications. Once the detailed project plan is approved by the Procuring Agency, the following sections detail the process for submission and review of Deliverables during the life of the project/Contract.

Documentation Deliverables 1. General

a. When submitting a documentation Deliverable for review and acceptance, the Contractor shall post the deliverable to a secure, password protected SharePoint site for retrieval by designated Procuring Agency staff. If requested, Contractor shall supply hard copies to the Procuring Agency Project Manager as identified in the Contract.

b. Once a Deliverable is approved and accepted by the Procuring Agency,

the Contractor shall provide a final updated and corrected electronic copy via the SharePoint site. The Procuring Agency may, at its discretion, waive this requirement for a particular Deliverable.

c. The electronic copy shall be provided in software currently utilized by the

Procuring Agency or provided by the Contractor.

d. Deliverables will be evaluated by the Procuring Agency under Quality Assurance.

2. Deliverable Submission

a. Prior to development and submission of each Contract Deliverable, the Contractor will submit an annotated outline of the Deliverable to the Procuring Agency Project Manager for review and approval.

b. Deliverables shall be developed by the Contractor according to the

approved format and content of the approved outline for each specific Deliverable.

c. At a mutually agreed to meeting, on or before the time of delivery to the




Procuring Agency, the Contractor shall schedule and provide a walkthrough of each Deliverable to be presented.

d. Deliverables shall be submitted no later than 5:00 PM, per the approved

Contract Deliverable schedule and shall be accompanied by a Deliverable sign-off form with the appropriate sections completed by the Contractor.

3. Deliverable Review

a. General

1) The Procuring Agency’s review time begins on the next working day following receipt of the Deliverable.

2) The Procuring Agency’s review time will vary by Deliverable, and

will be defined in the table at the end of this section or by Article 4 of the Agreement if not included in the table.

3) The Procuring Agency has up to one (1) working day to determine if

a Deliverable is complete and ready for review. Unless otherwise negotiated, this is part of the Procuring Agency’s review time.

4) Any subsequent Deliverable, whose requirements are directly

dependent upon a prior Deliverable, will not be accepted for review until the previous Deliverable has been accepted.

5) After review of a Deliverable, the Procuring Agency will return to the

Contractor the project Deliverable sign-off form (attached to the end of this Exhibit) with the Deliverable submission and review history section completed.

b. Accepted

1) If the Deliverable is accepted, the original Deliverable sign-off form

signed by the appropriate Procuring Agency representatives will be returned to the Contractor.

2) Once the Contractor receives the original Deliverable sign-off form,

the Procuring Agency can then be invoiced for the Deliverable per the procedures set out in the Agreement.

c. Rejected - Comments/Revisions Requested by the Procuring Agency

If the Procuring Agency has comments and/or revisions to a Deliverable,




the following will be provided to the Contractor: 1) The original Deliverable sign-off form with an updated entry to the

Deliverable submission and review history section.

2) Attached to the Deliverable sign-off form will be a detailed explanation of

the revisions to be made and/or a marked up copy of the Deliverable.

3) The Procuring Agency’s first review and return with comments will be

completed within the times specified in the Agreement.

4) The Contractor will have fifteen (15) days, unless otherwise mutually

agreed to, for review, acceptance and/or rejection of the Procuring Agency’s comments, and resubmission of the Deliverable.

5) A meeting (called by the Contractor) to resolve outstanding issues shall

be completed within five (5) working days after completion of the Contractor’s review or a mutually agreed upon time frame.

6) Agreements made during meetings to resolve issues shall be

documented and attached to the Deliverable sign-off form. Any such Agreements are not Amendments to the Contract. Amendments to the Contract shall follow the procedures set out in Article 25 of this Agreement.

7) Once an agreement is reached regarding changes, the Contractor shall

incorporate them into the Deliverable for resubmission to the Procuring Agency.

8) All changes shall be easily identifiable by the Procuring Agency.

9) Resubmission of the Deliverable shall occur within fifteen (15) days or a

mutually agreed upon time frame of the resolution of any outstanding issues.

10) The resubmitted Deliverable shall be accompanied by the original

Deliverable sign-off form.

11) The Contractor will have the opportunity to resubmit a Deliverable to the

Agency a minimum of three times per Article 4(c) of the Agreement.

12) During the re-review process, the Procuring Agency may only comment

on the original exceptions noted, unless changes to the Deliverable cause new issues to arise.

13) All other items not originally commented on are considered to be

acceptable by the Procuring Agency, unless changes to the Deliverable




cause new issues to arise.

14) Once all revisions have been accepted, the original Deliverable sign-off

form signed by the appropriate Procuring Agency representatives will be returned to the Contractor.

15) The Contractor shall provide one (1) updated and complete master paper,

if applicable, and associated electronic copy of each Deliverable after approval and acceptance by the Procuring Agency.

Software Product Deliverables

1) When submitting a nonfunctioning prototype Deliverable, the

Procuring Agency will sign off on the final screen prototypes presented during acceptance at the final sprint cycle meeting for the particular nonfunctional prototype module.

2) When submitting a functioning software Deliverable, the Procuring Agency will sign off on acceptance test criteria for the functioning software presented during acceptance at the final sprint cycle meeting for the particular functioning software module.