laboratory information management system lims …€¦ · the primary uses of the project plan are...

LLAABBOORRAATTOORRYY IINNFFOORRMMAATTIIOONN MMAANNAAGGEEMMEENNTT SSYYSSTTEEMM ((LLIIMMSS))

PPRROOJJEECCTT MMAANNAAGGEEMMEENNTT PPLLAANN ((PPMMPP))

EXECUTIVE SPONSOR – DR. DAVID MILLS

BUSINESS OWNER – DR. DAVID MILLS PROJECT MANAGER – TIM ELSBROCK

ORIGINAL PLAN DATE: AUGUST 18, 2005 REVISION DATE: NOVEMBER 19, 2007

REVISION: 1.0

PROJECT MANAGEMENT PLAN FOR [PROJECT NAME]

REVISION: 1.0 DOIT-PMO-TEM-020 i OF vi

REVISION HISTORY............................................................................................................................................ III PREPARING THE PROJECT MANAGEMENT PLAN ................................................................................................ IV ABOUT THIS DOCUMENT................................................................................................................................... IV

PROJECT OVERSIGHT PROCESS MEMORANDUM – DOIT, JULY 2007............................................................... IV PROJECT OVERSIGHT PROCESS MEMORANDUM – DOIT, JULY 2007............................................................... IV

1.0 PROJECT OVERVIEW ..................................................................................................................................... 1 1.1 Executive Summary‐ rationale for the Project................................................................................................1 1.2 funding and sources .......................................................................................................................................1 1.3 Constraints .....................................................................................................................................................2 1.4 Dependencies .................................................................................................................................................2 1.5 Assumptions ...................................................................................................................................................3 1.6 Initial Project Risks Identified ........................................................................................................................3

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE............................................................................ 4 2.1 Stakeholders...................................................................................................................................................4 2.2 Project Governance Structure ........................................................................................................................5 2.2.1 Describe the organizational structure – Org Chart .....................................................................................5 2.2.2 Describe the role and members of the project steering committee............................................................6 2.2.3 Organizational Boundaries, interfaces and responsibilities ........................................................................6 2.3 Executive Reporting........................................................................................................................................7

3.0 SCOPE .......................................................................................................................................................... 8 3.1 Project Objectives...........................................................................................................................................8 3.1.1 Business Objectives .....................................................................................................................................8 3.1.2 Technical Objectives ....................................................................................................................................9 3.2 Project Exclusions .........................................................................................................................................10 3.3 Critical Success Factors.................................................................................................................................10

4.0 PROJECT DELIVERABLES AND METHODOLOGY .............................................................................................10 4.1 Project Management Life Cycle....................................................................................................................10 4.1.1 Project Management Deliverables ............................................................................................................11 4.1.2 Deliverable Approval Authority Designations ...........................................................................................12 4.1.3 Deliverable Acceptance Procedure............................................................................................................13 4.2 Product Life Cycle .........................................................................................................................................13 4.2.1 Technical Strategy .....................................................................................................................................14 4.2.2 Product and Product Development Deliverables.......................................................................................14 4.2.3 Deliverable Approval Authority Designations ...........................................................................................16 4.2.4 Deliverable Acceptance Procedure............................................................................................................16

5.0 PROJECT WORK ...........................................................................................................................................16 5.1 Work Breakdown Structure (WBS) ...............................................................................................................16 5.2 Schedule allocation ‐ Project Timeline..........................................................................................................17 5.3 Project Budget..............................................................................................................................................18 5.4 Project Team ................................................................................................................................................19 5.4.1 Project Team Organizational Structure.....................................................................................................19 5.4.2 Project Team Roles and Responsibilities ...................................................................................................20 5.5 STAFF PLANNING AND Resource ACQUISITION............................................................................................21 5.5.1 Project Staff...............................................................................................................................................21 5.5.2 Non‐Personnel resources...........................................................................................................................22 5.6 PROJECT LOGISTICS ......................................................................................................................................23


REVISION: 1.0 DOIT-PMO-TEM-020 ii OF vi

5.6.1 Project Team Training ...............................................................................................................................23 6.0 PROJECT MANAGEMENT AND CONTROLS ....................................................................................................24

6.1 Risk and issue Management ........................................................................................................................24 6.1.1 Risk Management Strategy.......................................................................................................................24 6.1.2 Project Risk Identification..........................................................................................................................24 6.1.3 Project Risk Tracking Approach.................................................................................................................24 6.1.4 ISSUE MANAGEMENT................................................................................................................................25 6.2 INDEPENDENT Verification and Validation ‐ IV&V .......................................................................................26 6.3.1 Change Control..........................................................................................................................................27 6.4 Project Budget Management .......................................................................................................................28 6.4.1 Budget Tracking ........................................................................................................................................29 6.5.1 Communication Matrix .............................................................................................................................29 6.5.2 Status Meetings ........................................................................................................................................29 6.5.3 Project Status Reports ...............................................................................................................................29 6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) .................................................................................29 6.6.1 Baselines....................................................................................................................................................30

6.7 QUALITY OBJECTIVES AND CONTROL ...........................................................................................................30 6.7.1 quality Standards ......................................................................................................................................30 6.7.2 Agency/Customer Satisfaction ..................................................................................................................32 6.7.3 PRODUCT DELIVERABLE ACCEPTANCE PROCESS.......................................................................................32

6.8 CONFIGURATION MANAGEMENT ................................................................................................................33 6.8.1 Version Control..........................................................................................................................................33 6.8.2 Project Repository (Project Library)...........................................................................................................33

6.9 PROCUREMENT MANAGEMENT PLAN..........................................................................................................33 7. 0 PROJECT CLOSE...........................................................................................................................................34

7.1 Administrative Close.....................................................................................................................................34 7.2 Contract Close ..............................................................................................................................................34


REVISION: 1.0 DOIT-PMO-TEM-020 iii OF vi

RREEVVIISSIIOONN HHIISSTTOORRYY

RREEVVIISSIIOONN NNUUMMBBEERR DDAATTEE CCOOMMMMEENNTT

1.0 July 27th, 2007 DoIT Project Management Office Revision

2.0

2.1

2.2


REVISION: 1.0 DOIT-PMO-TEM-020 iv OF vi

PPRREEPPAARRIINNGG TTHHEE PPRROOJJEECCTT MMAANNAAGGEEMMEENNTT PPLLAANN

The workbook for preparation of the Project Management Plan is built around helping the project manager and the project team to use the Project Management Plan in support of successful projects. Please refer to it while developing this PMP for your project.

AABBOOUUTT TTHHIISS DDOOCCUUMMEENNTT

Project Oversight Process Memorandum – DoIT, July 2007

“Project management plan” is a formal document approved by the executive sponsor and the

Department and developed in the plan phase used to manage project execution, control, and project close.

The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost and schedule baselines.

A project plan includes at least other plans for issue escalation, change control, communications, deliverable review and acceptance, staff acquisition, and risk management.

“Project manager” means a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan, execute, control, close). The project manager must be familiar with project scope and objectives, as well as effectively coordinate the activities of the team. In addition, the project manager is responsible for developing the project plan and project schedule with the project team to ensure timely completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department.

Project product” means the final project deliverables as defined in the project plan meeting all agreed and approved acceptance criteria.

“Product development life cycle” is a series of sequential, non-overlapping phases comprised of iterative disciplines such as requirements, analysis and design, implementation, test and deployment implemented to build a product or develop a service.


11..00 PPRROOJJEECCTT OOVVEERRVVIIEEWW 11..11 EEXXEECCUUTTIIVVEE SSUUMMMMAARRYY-- RRAATTIIOONNAALLEE FFOORR TTHHEE PPRROOJJEECCTT The New Mexico Department of Health’s Scientific Laboratory Division (SLD) currently utilizes a number of stand-alone applications and data sets to meet its laboratory information system needs. The current systems utilize a combination of manual processes and electronic technologies.

The SLD is receiving increasing demands from regulatory agencies, key clients and partners to modernize its information systems. Necessary functionality, such as required electronic reporting formats, privacy controls, electronic data exchange with clients and regulatory agencies (Centers for Disease Control, Environmental Protection Agency), internal tracking of specimens, and the ability to collect and analyze required quality assurance data, is not currently in place. The ability to manage the entire SLD operation from one computer screen, in a holistic manner is impossible under the current IT infrastructure, as the current information management system is based upon a laboratory section-by-laboratory section “ledger system” (lab section-specific listing of specimens) that is merely an electronic version of the paper-based recording system used by the laboratory 20 years ago. In the current system, specimens are only viewable and can only be queried from within each ledger.

SLD receives more than 150,000 samples a year that result in over 700,000 unique test results. In the existing system, all of these samples are managed by a numeric identifier that has to be manually entered multiple times, i.e. each time an analyst enters or retrieves information on a sample. The LIMS implementation will result in a barcode system whereby samples will be traceable through the entire lab with a single pass of the work order by a barcode reader or by a single query. The current silo structure will be eliminated so that the location and status of a sample will be viewable by a single query. This increased capability will significantly augment the business processes within the laboratory by enabling management to monitor processes and turn around times and also to track work loads for the laboratory’s numerous clients. The latter will indirectly facilitate SLD billing processes and increase accountability to DOH administration and the legislature by improving the accuracy of performance measures. The LIMS implementation will also enhance the electronic data transfer capabilities between SLD and its clients, allowing data transfer directly in formats required by clients, e.g. HL 7 messaging and Safe Drinking Water Information System (SDWIS) formats. Currently, data are transferred in flat files and must be manually converted to required formats.

Since the project was originally certified, the LIMS project has reviewed the COTS products currently on the market, performed extensive analysis of current and desired business processes, generated detailed system requirements, issued an RFP, and is currently in contract negotiations with the selected vendor.

11..22 FFUUNNDDIINNGG AANNDD SSOOUURRCCEESS

Fiscal Year

Amount Funding Source(s)

FY06 $1,000,000 $1,000,000 - Laws 2005, Chapter 33, Section 7, Subsection 23

PAGE | 1


FY07 $108,550 $1,000,000 (extended from FY06) – Laws 2006, Chapter 109, Section 7, Subsection 20 $108,550 – Preparedness and Response to Bioterrorism Grant (CDC Cooperative Agreement U90/CCU616999-05)

FY08 $771,436 $1,000,000 (extended from FY05 and FY06) – Laws 2007, Chapter 28, Section 7, Subsection 25 $554,000 – Preparedness and Response to Bioterrorism Grant (CDC Cooperative Agreement U90/CCU616999-05) $217,436 – Scientific Laboratory Division Operating Budget – Laws 2007, Chapter 28, Section 4, Subsection F, DOH, Paragraph 3, Page 145

11..33 CCOONNSSTTRRAAIINNTTSS Constraints are factors that restrict the project by scope, resource, or schedule.

NNUUMMBBEERR DDEESSCCRRIIPPTTIIOONN

1 Scope of the LIMS is constrained to workflow and process automation for the handling of samples and subsequent analysis.

2 Configuration of the LIMS post implementation will be constrained by available IT resources. While the initial implementation will address core workflow improvement, future configuration will have to be prioritized by the Change Control Board.

11..44 DDEEPPEENNDDEENNCCIIEESS Types include the following and should be associated with each dependency listed.

• Mandatory dependencies are dependencies that are inherent to the work being done. • D- Discretionary dependencies are dependencies defined by the project management team. This may also

encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.

• E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement

NNUUMMBBEERR DDEESSCCRRIIPPTTIIOONN TTYYPPEE MM,,DD,,EE

1 Project dependent on agreed price, terms, timelines between Agency and Vendor

M

2 Project dependent on budgetary resources being carried over from FY08 to FY09

D

3 Project timeline dependent on schedule of Vendor E

PAGE | 2


11..55 AASSSSUUMMPPTTIIOONNSS Assumptions are planning factors that, for planning purposes, will be considered true, real, or certain.


1 The Scientific Laboratory Division of the State of New Mexico Department of Health will secure adequate funding for the planning, execution, and implementation of the LIMS.

2 The LIMS project will procure the services of a third-party to perform the project scope of work and implementation

11..66 IINNIITTIIAALL PPRROOJJEECCTT RRIISSKKSS IIDDEENNTTIIFFIIEEDD

Probability: Expected Impact :: HIGH

Mitigation Strategy : Heavy user training, translation of existing tables where possible, executive leadership stressing importance of user acceptance

Description – User acceptance of LIMS workflow

Contingency Plan : Retraining of users, increase training on code translations from old system to new system, rework LIMS configuration options to make reasonable accommodations to justifiable concerns Probability: Likely Impact: Medium

Mitigation Strategy: Currently working with selected LIMS vendor before contract negotiations are complete.

Description – Misunderstood requirements

Contingency Plan: SLD is bringing the LIMS administrators (primary and backup) into ALL committee meetings and technical discussions upfront to have technical understanding of each requirement. There is also $100,000 of funding in current budget that could be used for System configuration post implementation. Probability: Likely (LIMS Project lost $100,000 in federal grant funds due to delay of an approved social services architecture pursuant to Laws 2005, Chapter 33, Section 7, Subsection 23)

Impact : Medium Description - Funding

Mitigation Strategy: SLD is aware of tight budget through project completion. Executive sponsor has spent time considering various streams of funding to cover what would be a small shortfall within a project with a $2M total budget

PAGE | 3


Contingency Plan: Reduce consulting work at final implementation phase; bring in more configuration work for SLD admins. Postpone some instrument interface configurations with environmental systems until SLD moves into new building. There are several ways to cover the shortfall which will be small should it even materialize. Moreover, all assumptions to date are based on no expansion of SLD operating budget. Probability: Unlikely Impact :: Medium

Mitigation Strategy: SLD will make all changes to LIMS under a change control process. Required configurations will be generated from the bench level working analysts and pushed into the change control process for authorization.

Description - Internal staffing issues

Contingency Plan: There will be two admins at SLD that are trained to perform the full admin role, should one have to be replaced. Additionally, the LIMS PM will also end up as a trained admin. Additional training will be available in case of staff turnover.. Probability: Likely Impact :: Medium

Mitigation Strategy: ITSD is conducting a Network Assessment to confirm existing bandwidth capacity is sufficient to support expected LIMS response times.

Description – Insufficient network capacity

Contingency Plan: Network Assessment will provide recommendations which will be implemented in coordination with DoIT to mitigate this risk. Probability: Likely Impact : Medium

Mitigation Strategy: The lab will increasingly depend on communication protocols into and out of the LIMS. To mitigate, one of each known protocol will be implemented.

Description - Technical Dependencies

Contingency Plan: Protocols and technical dependencies expected to arise will be accommodated within the support plan. Will attempt to work on each known protocol during implementation. Also working with major state and federal interfaces that will be looking for SLD data feeds as way to get such protocols functionally in place. Much of this is still under development by the external parties.

22..00 PPRROOJJEECCTT AAUUTTHHOORRIITTYY AANNDD OORRGGAANNIIZZAATTIIOONNAALL SSTTRRUUCCTTUURREE

The Project Organization describes the roles and responsibilities of the project team. It also identifies the other organizational groups that are part of the project and graphically depicts the hierarchical configuration of those groups. It exists to clarify interaction with the project team.

22..11 SSTTAAKKEEHHOOLLDDEERRSS

NNAAMMEE OORR TTIITTLLEE SSTTAAKKEE IINN PPRROOJJEECCTT OORRGGAANNIIZZAATTIIOONN

PAGE | 4


NNAAMMEE OORR TTIITTLLEE SSTTAAKKEE IINN PPRROOJJEECCTT OORRGGAANNIIZZAATTIIOONN

David Mills Scientific Laboratory Division Director

Scientific Laboratory Division

SLD Management Lab Operations Scientific Laboratory Division

Regulatory Agencies Oversight of Laboratory Environmental Protection Agency (EPA), Food and Drug Administration (FDA)

DOH Programs More Timely Results Department of Health

Other Clinical Labs More Timely Ordering And Results

SED, Tricore, Etc.

Providers More Timely Ordering And Results

Various

CDC More Timely Reporting Center for Disease Control

Citizens Of NM More Timely Health Action New Mexico

22..22 PPRROOJJEECCTT GGOOVVEERRNNAANNCCEE SSTTRRUUCCTTUURREE

22..22..11 DDEESSCCRRIIBBEE TTHHEE OORRGGAANNIIZZAATTIIOONNAALL SSTTRRUUCCTTUURREE –– OORRGG CCHHAARRTT

PAGE | 5


David MillsExecutive Project Sponsor

Project Director Twila Kunde

Tim ElsbrockProject Manager

Advisory Committee

DOH LIMSSteering

Committee

PHIN Master Project

Steering Committee

IV&V Contractor

Business Process Team Technical Team

22..22..22 DDEESSCCRRIIBBEE TTHHEE RROOLLEE AANNDD MMEEMMBBEERRSS OOFF TTHHEE PPRROOJJEECCTT SSTTEEEERRIINNGG CCOOMMMMIITTTTEEEE The Steering Committee is chartered to provide governance over the direction and support of the project and is chaired by the Project Director. The Steering Committee member responsibilities include: • Attend and participate in meetings • Review and accept deliverables • Review presented documentation • Balance larger picture versus details of project • Review project funding and expenditures • Champion the project

• Contribute to lessons learned

22..22..33 OORRGGAANNIIZZAATTIIOONNAALL BBOOUUNNDDAARRIIEESS,, IINNTTEERRFFAACCEESS AANNDD RREESSPPOONNSSIIBBIILLIITTIIEESS Use this section to describe any special considerations regarding contact between the project team, the project manager, and individuals from various organizations involved in the project: Boundary, interface and responsibilities at the interface

PAGE | 6


Deliverable/Description Target Audience

Delivery Method

Frequency Responsible Party

Monthly DOH Status DOH CIO Face-to-Face

Monthly/Upon Request

Project Manager

CDC BT Grant Project Status

Funding Source Written Quarterly/Upon Request

Project Director/Project Manager

Weekly Project Status Project Team Members/Project Director

Email/Face-to-Face

Weekly Project Team Members

Project Team Meeting Project Team Members/Project director

Face-to-Face

Weekly Project Team Members/Project Manager

Steering Committee Meeting

Committee Members

Face-to-Face

Monthly Project Director

PHIN Master Project Steering Committee Meeting

Committee Members

Face-to-Face

Quarterly Project Director/Project Manager

Ad hoc As needed As needed As needed As needed

Project Dashboard All Web As needed Project Manager

Monthly Department of Information Technology project reports

Department of Information Technology

FTP Monthly Project Manager

22..33 EEXXEECCUUTTIIVVEE RREEPPOORRTTIINNGG

Meeting agendas, minutes, and supporting documentation will be provided using the following software packages: Microsoft Word, Excel, PowerPoint, Outlook and Project. Every attempt will be made to publish the meeting minutes in a timely fashion and no later than 2 days prior to the next regularly scheduled meeting. Any meeting called should have an agenda, attempt to start on time and finish on time. The time allocated to each agenda topic will vary depending on the depth of issues to be covered. Items not able to be covered within the meeting time and accepted to be postponed may be added to the next standing meeting’s agenda or may require a special session.

The meeting times and distributions of the meeting minutes for the LIMS Project are as follows:

PAGE | 7


Project Team Meetings will be on a regular schedule. The scribe will be assigned by the Project Manager. The project team meetings will be posted in the paper-based and electronic document libraries by the Project Manager.

Monthly Steering Committee Meetings will continue to be held every month. The scribe will be assigned by the Project Director. The Monthly Steering Committee meeting minutes will be posted to the electronic document library in the LIMS Project folder and e-mailed to attendees.

Special Session Meetings may be called at the request of the Project Director or Project Manager. A range of issues may require a special meeting of a team, committee or subset. These meetings will be scheduled to accommodate the majority of attendees. The minutes from these meetings will be posted in the document library and possibly e-mailed depending on the location of the attendees.

Status reports will be used to track progress and issues. The Project Manager will provide bi-monthly project status reports to the LIMS Project Director, and Steering Committee. Project Team members will provide status reports as requested by the Project Manager. These reports will be in addition to such reports prepared upon request and by other contractors.

Special reports will be provided at the request of the LIMS Project Management Contract Administrator or the Project Director.

Deliverable sign-offs will be used for approval purposes and will be archived in the physical project library in the Project Manager’s office.

Issue management and resolution helps to resolve those issues not anticipated during planning process. Issues should be reported at the earliest possible time so that corrective action can be developed to deal with the issue. The corrective action should address both the immediate need and the underlying cause of the issue. The Project Manager will keep an issue tracking log and will work with the Project Team for corrective action.

The Project Manager will maintain an action item list. This action item list identifies the action item, reference item, responsible party, solution, due date, and completion date. Updates may also be reflected in meeting minutes.

33..00 SSCCOOPPEE 33..11 PPRROOJJEECCTT OOBBJJEECCTTIIVVEESS

33..11..11 BBUUSSIINNEESSSS OOBBJJEECCTTIIVVEESS

Description Compliance with Federal regulations and industry standards as dictated by Clinical Laboratory Improvement Act (CLIA), Health Insurance Portability and Accountability Act of 1996 (HIPAA), and the Environmental Protection Agency (EPA).

Rationale Mandated by multiple parties that regularly interact with SLD

Acceptance Criteria

HL7 interface functioning by end of FY09

PAGE | 8


Description Ability to manage all lab sample submissions and reporting from within a single system

Rationale Efficient management will improve overall SLD operations

Acceptance Criteria

100% of submission can be tracked through entire lab within one application interface

Description Ability to utilize technology across the entire lab as SLD completes the new building in 2011

Rationale Ability to integrate rooms, environmental, and testing equipment will be available for the move into the $90M building. SLD should break ground in FY08.

Acceptance Criteria

That integration of environmental systems by end FY09

Description Consolidation and the decommissioning of servers running the disparate databases that now exist across SLD.

Rationale Cost and resources savings, Mandated by DoIT

Acceptance Criteria

Servers to be replaced will com off lien one replacement functionality has been tested and put into production.

33..11..22 TTEECCHHNNIICCAALL OOBBJJEECCTTIIVVEESS

OOBBJJEECCTTIIVVEE DDEESSCCRRIIPPTTIIOONN

Enable digital audit trail and Chain of Custody

Allows lab to report on; sample handling, calibrations, analyst performing the tests, sample location. This is all done manually today.

Enable web access to results

The LIMS will allow SLD to communicate with partners via the web. Will also allow individuals to access their results remotely via the web.

Manage all samples via barcode

Reduce repetitive data entry by utilizing barcodes for every sample

PAGE | 9


33..22 PPRROOJJEECCTT EEXXCCLLUUSSIIOONNSS The LIMS is a system designed specifically to handle sample submission and tracking. The LIMS is not design to handle operational activities across the lab such as:

• Inventory management of supplies not directly related to tests

• Scheduling of workforce or resources

• Facility resources management

• Specimen security concerns outside of audit trail and chain of custody tracking

33..33 CCRRIITTIICCAALL SSUUCCCCEESSSS FFAACCTTOORRSS


1 All samples entering SLD are entered into the LIMS, have barcodes applied, are traceable throughout SLD, and have results generated automatically.

2 LIMS system is compatible with the data standards of SLD’s partners

44..00 PPRROOJJEECCTT DDEELLIIVVEERRAABBLLEESS AANNDD MMEETTHHOODDOOLLOOGGYY 44..11 PPRROOJJEECCTT MMAANNAAGGEEMMEENNTT LLIIFFEE CCYYCCLLEE

Phase Summary of Phase Key Deliverables

Initiation Develop scope and high level objectives of project

Business Case, Project Charter

Planning Development of what a successful project looks like. Requirements document that translates functional tasks into product requirements. Selection of vendor to meet the defined requirements.

Project Management Plan, Product requirements, ‘as is’ and ‘to be’ workflow diagrams for each section within SLD, RFP

Implementation Execute contract with vendor to fulfill the product requirements. Define development, test and acceptance criteria and execute.

Contract with vendor, work plan, system testing and acceptance. System enters production. Creation of Change Control Board (CCB)

PAGE | 10


Closeout Document requirements are fulfilled by product, system has entered production and ownership transferred to Application Support Bureau (ASB)

Application Support Plan (ASP) is completed and accepted. CCB takes control of configuration request prioritization.

44..11..11 PPRROOJJEECCTT MMAANNAAGGEEMMEENNTT DDEELLIIVVEERRAABBLLEESS Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project.

4.1.1.1 PROJECT PROPOSAL Deliverable Acceptance Criteria: Project deemed necessary and budget allocations can cover estimated costs Standards for Content and Format -

Project Proposal communicates the need for the project and what benefits will be derived once completed

Quality Review - Acceptance by DOH Leadership

4.1.1.2 BUSINESS CASE

Deliverable Acceptance Criteria – Business case accepted due to detail cost benefit analysis and overall appropriateness of objectives

Standards for Content and Format - Budget estimates balanced against expected return, completeness of business objectives

Business case describes the technical problem that will be resolved via project completion

Quality Review - Acceptance by DOH Leadership

4.1.1.3 PROJECT MANAGEMENT PLAN

Deliverable Acceptance Criteria – Processes and resources thoroughly explained, GAPS identified, implementation plan ready

Standards for Content and Format - Document completed according to standard Project Management worksheets

Documentation of overall thoroughness of project concept, required processes to achieve completion

Quality Review - Acceptance by Steering Committee

4.1.1.4 PROJECT SCHEDULE

PAGE | 11


Deliverable Acceptance Criteria – Reasonable assumption for completion times, recorded actual times for completed items

Standards for Content and Format - MS Project file

Document that tracks excepted and actual timeline for tasks and subtasks

Quality Review - Acceptance by Steering Committee

4.1.1.5 PROJECT CERTIFICATION DOCUMENT

Deliverable Acceptance Criteria – In conjunction with certification presentation

Standards for Content and Format - Per DoIT template

DoIT requirement that documents high-level Business case, technical objectives, schedules, tasks and subtasks

Quality Review - Acceptance by DoIT

4.1.1.6 APPLICATION SUPPORT PLAN

Deliverable Acceptance Criteria – Sign-off by all supporting groups

Standards for Content and Format - Per Application Support Bureau (ASB)

Detailed accounting of tasks and roles/resources needed for transition to full production

Quality Review - Acceptance by ITSD Leadership

44..11..22 DDEELLIIVVEERRAABBLLEE AAPPPPRROOVVAALL AAUUTTHHOORRIITTYY DDEESSIIGGNNAATTIIOONNSS Complete the following table to identify the deliverables this project is to produce, and to name the person or persons who have authority to approve each deliverable.

DDEELLIIVVEERRAABBLLEE NNUUMMBBEERR

DDEELLIIVVEERRAABBLLEE AAPPPPRROOVVEERRSS ((WWHHOO CCAANN AAPPPPRROOVVEE))

DDAATTEE AAPPPPRROOVVEEDD

PRJ-DEL-001 Project Management Plan (PMP) Executive Sponsor, DoIT

Project Charter Executive Sponsor, DoIT

Project Schedule Steering Committee

Implementation Phase user acceptance

Steering Committee

LIMS system Documentation Steering Committee

Final LIMS system acceptance Steering Committee

PAGE | 12


44..11..33 DDEELLIIVVEERRAABBLLEE AACCCCEEPPTTAANNCCEE PPRROOCCEEDDUURREE LIMS project Steering Committee will sign off on all deliverables.

During implementation phase, the Steering Committee will review testing schedules and progress reports from user testing and accept or reject accordingly. Project Manger will align acceptance to original product requirements and to be work flow diagrams for closeout documentation.

44..22 PPRROODDUUCCTT LLIIFFEE CCYYCCLLEE

Phase Summary of Phase Key Deliverables

Initiation Develop end vision and scope Project Charter

Plan Requirement development, initial budget allocations and sources documented

Requirements document

Define Secure funding sources, review available COTS, initiate negotiations

Initial budget appropriations, RFP and subsequent product demonstrations

Design Enforceable contract in place, start to build the LIMS

Signed contract, develop and test environments in place

Build Product configuration begins Functional AP specification resolved and agreed to

Pilot Initial users testing Test environment available for end-user testing, new workflow diagrams published, code translations published, user manuals customized and published

Deploy LIMS deployed within each sections that has completed the above. Will repeat for each of SLD’s sections

Product enters production. User testing scripts vetted, product becomes available to all within section replete with documentation

Close Product is accepted by respective section via written notice to vendor

Written acceptance

PAGE | 13


44..22..11 TTEECCHHNNIICCAALL SSTTRRAATTEEGGYY

Software Acquire and deploy a Commercial off the Shelf (COTS) LIMS application that:

• Designed specifically to handle testing laboratory workflows

• Has a Chain of Custody (COC) and Audit Trail reporting functionality

• Uses barcode for tracking of lab samples

• Open architecture to accommodate communication standards

• Configurable to support future workflow

Hardware

• Procure servers to host selected COTS

• Redundant server configurations to avoid single point of failure

• Manual failover to minimize downtown due to failure event

• Barcode scanners across lab to track sample movement within SLD

• LIMS database to hold current year +2 of sample and test data

• Data backup to and off site storage of removable media

44..22..22 PPRROODDUUCCTT AANNDD PPRROODDUUCCTT DDEEVVEELLOOPPMMEENNTT DDEELLIIVVEERRAABBLLEESS Product Deliverables are work products or artifacts that are driven by the product management methodology requirements and standard project management practices regardless of the product requirements of the project.

4.2.2.1 FUNCTIONAL REQUIREMENTS DOCUMENT Deliverable Acceptance Criteria – Documents reviewed by requirements committee and accepted as communicating required functionality to level of detail such that a LIMS system can be configured to deliver said functionality Standards for Content and Format – Individual requirements numbered and grouped by related functions and sections.

Document details functionality required for a successful LIMS implementation

Quality Review – LIMS requirements committee, IV&V review

4.2.2.2 TECHNICAL REQUIREMENTS DOCUMENT

PAGE | 14


Deliverable Acceptance Criteria - Documents reviewed by requirements committee and accepted as communicating required functionality to level of detail such that a LIMS system can be configured to deliver said functionality

Standards for Content and Format - Individual requirements numbered and grouped by related functions and sections.

Document details technical specifications and capabilities required for a successful LIMS implementation

Quality Review - LIMS requirements committee, ITSD Application Support and Production Services Bureau

4.2.2.3 AS IS AND TO BE WORKFLOW DIAGRAMS

Deliverable Acceptance Criteria - Documents reviewed by requirements committee and accepted as correctly documenting depicting workflows

Standards for Content and Format - Flow chart diagrams

Document details the workflows as they are currently in SLD, and how they will be once the LIMS is implemented. This is completed for each section within SLD.

Quality Review - LIMS requirements committee, IV&V review

4.2.2.4 HARDWARE CONFIGURATION DOCUMENT

Deliverable Acceptance Criteria - Documents reviewed by requirements committee and ITSD Network Operations Group.

Standards for Content and Format - System configuration specifications, network architecture,

Document specifies the hardware configuration required to delivered expected system performance

Quality Review - LIMS requirements committee and ITSD network operations group.

4.2.2.5 SOFTWARE CONFIGURATION DOCUMENT

Deliverable Acceptance Criteria - Documents reviewed by requirements committee and ITSD Application Services Bureau

Standards for Content and Format - Software configuration specifications, maintenance and support plans, escalations process and user support plans

Document specifies the Software configuration required to delivered expected system performance

Quality Review - LIMS requirements committee and ITSD Applications Services Bureau

PAGE | 15


44..22..33 DDEELLIIVVEERRAABBLLEE AAPPPPRROOVVAALL AAUUTTHHOORRIITTYY DDEESSIIGGNNAATTIIOONNSS Please see the Work Breakdown Structure Below

44..22..44 DDEELLIIVVEERRAABBLLEE AACCCCEEPPTTAANNCCEE PPRROOCCEEDDUURREE LIMS project Steering Committee will sign off on all deliverables.

During implementation phase, the Steering Committee will review testing schedules and progress reports from user testing and accept or reject accordingly. Project Manger will align acceptance to original product requirements and to be work flow diagrams.

55..00 PPRROOJJEECCTT WWOORRKK 55..11 WWOORRKK BBRREEAAKKDDOOWWNN SSTTRRUUCCTTUURREE ((WWBBSS)) The WBS provided below will be completed for each distinct section within the Lab.

Task Acceptance Done Define Customer Project Team Steering Committee Approval y Assign LIMS Administrator Steering Committee Approval y Define Project Board Steering Committee Approval y Prepare/finalize as-is workflows for each laboratory section Steering Committee Approval y System Environment Plan (draft) ITSD Installation of Development Environment ITSD SOW / Project Plan Steering Committee Approval Establish Kick-off date Steering Committee Approval Initiation Stage

Kick-off Section Bureau Chief General review of workflows for planning purposes Section Bureau Chief Testing Plan and Documentation Requirements Section Bureau Chief Project Plan Steering Committee Approval LIMS Administrator Training Section Bureau Chief Installation of VENDOR LIMS in development Section Bureau Chief Sign-off of Initiation Stage Steering Committee Approval

Lab Sections 1

Provide as-is workflows and other requirements details for sections 1 Section Bureau Chief Provide lists of analyses for sections 1 Section Bureau Chief Workflow reviews and interviews for sections 1 Section Bureau Chief Review existing functionality/configuration as applicable Section Bureau Chief Key User training Section Bureau Chief

Functional Specification - sections 1 Section Bureau Chief Define gap between workflows, analyses and template Section Bureau Chief

report requirements Section Bureau Chief system interface requirements Section Bureau Chief instrument interface requirements Section Bureau Chief Collect legacy static data or populate static data files Section Bureau Chief

PAGE | 16


analyses requirements Section Bureau Chief Draft Functional Spec Section Bureau Chief Review Functional Spec Section Bureau Chief Approve Functional Spec sections 1 Section Bureau Chief

Prototype Sections 1 Section Bureau Chief Configuration Activity Section Bureau Chief Prototype Reports Section Bureau Chief Configuration Reviews Section Bureau Chief

Final Configuration Approval based on Statements of Requirements Section Bureau Chief

System Completion Stage: Lab Sections 1 Section Bureau Chief Verify test environment Section Bureau Chief Prepare SQL scripts for migration to testing and production Section Bureau Chief Migrate completed objects to test environment Section Bureau Chief Migrate static data to test environment Section Bureau Chief Test Environment ready for user acceptance

testing Section Bureau Chief User Acceptance Testing Section Bureau Chief

Prepare user acceptance test scripts Section Bureau Chief Execute user acceptance test scripts Section Bureau Chief Resolve testing failures and retest Section Bureau Chief Retest Section Bureau Chief System Acceptance Section Bureau Chief Configuration for Lab Sections 1 Locked Section Bureau Chief

End-user Training Materials/User Guide Section Bureau Chief Prepare User Guides Section Bureau Chief Approve User Guides Section Bureau Chief

Roll Out Stage: Lab Sections 1 Section Bureau Chief Verify Production Environment Section Bureau Chief Migrate locked objects to production environment Section Bureau Chief Site 1 Section Bureau Chief

Set up client PC's and printers at lab site Section Bureau Chief End-user training Section Bureau Chief Go-live site 1 Section Bureau Chief

Repeat for site All of Chemistry, Biology and Toxicology

55..22 SSCCHHEEDDUULLEE AALLLLOOCCAATTIIOONN -- PPRROOJJEECCTT TTIIMMEELLIINNEE The project timeline is a high-level view of project activities with a focus on project milestones. The project timeline does not replace the need for a detailed project schedule and it is to highlight key events such as deliverable due dates and when go/no-go decisions are made.

The table below should provide a high level view of the project time line, or a summary-level Gantt chart can be used to meet the timeline requirement.

Please provide a more detailed project schedule as an attachment to this plan

PAGE | 17


Identifier Task/Activity Name

Resource Name

Milestone (Y/N)

Effort/ Duration

Start Finish Dependent Task

Project Definition Phase

Steering Committee

Y 90 days 9/05 9/05

Requirements Definition and RFP Development Phase

Requirements Committee

Y 150 days

9/05 2/06

RFP Process for LIMS Software

RFP Review Committee

Y 120 days

12/06 4/07

Review and scoring of received proposals

RFP Review Committee

Y 60 Days 4/07 6/07

Vendor Demos RFP Review Committee

N 120 days

2/07 5/07

Negotiate and execute contract with chosen LIMS vendor

Project Manager Y 210 days

6/07

IV&V Contract Project Manager N 60 days 9/07 12/07

55..33 PPRROOJJEECCTT BBUUDDGGEETT

Description FY06 FY07 FY08 FY09

Staff - Internal

$35,000 $90,000 $90,000

Consulting Services

$39,829 $80,171 $318,600 $525,280

Hardware $305,106

Software $286,000 $110,000

TTOOTTAALL $39,829 $115,171 $999,706 $725,280

PAGE | 18


Phases Amount Requested

M

MAAJJOORR DDEELLIIVVEERRAABBLLEE((SS))

DDUUEE DDAATTEESS

Initiation: $155,000 Detailed Product

Requirements Document, Project Charter

9/05 - 6/06

Planning: $253,925 RFP developed by LIMS

Implementation Specialist, IV&V Reviews, As Is Workflow Diagrams, To Be Workflow Diagrams

7/06 - 3/07

Implementation: $591,075 RFP Issuance, Vendor Selection, Contract Negotiations, IV&V Periodic Reports

4/07 – 1/08

$879,986 Execute contract, System Implementation and User Acceptance, LIMS Implementation testing, IV&V Periodic Reports

2/08 – 7/09

Closeout: DoIT Project Closure Report, Project Materials Archive, Closed Contract File

8/09

55..44 PPRROOJJEECCTT TTEEAAMM

55..44..11 PPRROOJJEECCTT TTEEAAMM OORRGGAANNIIZZAATTIIOONNAALL SSTTRRUUCCTTUURREE

PAGE | 19


55..44..22 PPRROOJJEECCTT TTEEAAMM RROOLLEESS AANNDD RREESSPPOONNSSIIBBIILLIITTIIEESS List the team members, their role, responsibility and functional manager. Make sure to include a comprehensive listing including those from the organization managing the project, business members involved to ensure business objectives are met and the vendor members that may have a specific role.

Name LIMS Project Role Membership

Barbara Dobie Specimen Receiving Project Team, Steering Committee, Requirements Committee

Twila Kunde SLD Deputy Director and Project Director

Project Team, Steering Committee, Requirements Committee

David Mills State Health Department Representative, Executive Sponsor

Executive Sponsor, Steering Committee

Deborah Horensky Chief, Biological Sciences Bureau Project Team, Steering Committee, Requirements Committee

Gary Oty Director, Quality, Safety, Security and Emergency Preparedness

Project Team, Steering Committee, Requirements Committee

Ginger Baker Toxicology Bureau Steering Committee

PAGE | 20


Danny Gray Lead LIMS administrator LIMS System Administrator, Requirements committee

Philip Adams Chief, Chemistry Bureau Project Team, Steering Committee, Requirements Committee

Rocky Baros Chief, Program Support Bureau Program Support

Rong Hwang Chief, Toxicology Bureau Project Team, Steering Committee, Requirements Committee

Tim Elsbrock Project Manager Non-voting Steering Committee member, Project Manager

Vinnie Gerercke IV&V Oversight

Guillermo Gomez Secondary LIMS administrator LIMS System Administrator, Requirements committee

Tom Woods Vendor: Public Health Program Manger

Project Team

Eric Vest Vendor: LIMS Project Manager Project Team

Adam Seale Vendor: LIMS Implementation Specialist

Project Team

55..55 SSTTAAFFFF PPLLAANNNNIINNGG AANNDD RREESSOOUURRCCEE AACCQQUUIISSIITTIIOONN

55..55..11 PPRROOJJEECCTT SSTTAAFFFF Resource

Cost Estimate

Estimated Hours

Availability Skill Set

Work Product/Deliverable

PAGE | 21


Project Manager 90,000 yr burdened

40/wk 100% LIMS admin training

Primary LIMS administrator

80,000/yr burdened

40/wk 100% LIMS admin training/XML training

Execution of configuration requests

Secondary LIMS administrator

$80,000/yr burdened

40/wk 50% LIMS admin training/XML training

Execution of configuration requests

LIMS Contractor $1.3M 16,000 100% Experience building, install, configuring and training of LIMS system

Configuration work plans, ‘To be’ workflow documents,

55..55..22 NNOONN--PPEERRSSOONNNNEELL RREESSOOUURRCCEESS Use this section to list services or product (HW/SW and such) needed for project Resource

Cost Estimate

Estimated units/hours Availability Source

Work Product/Deliverable

24 Workstations $29,000 Purchased LIMS Budget

2 Database servers $32,000 Will procure

LIMS Budget

6 File servers $68,000 Will procure

LIMS Budget

84 Barcode scanners $30,000 Will procure

LIMS Budget

30 Barcode printers $48,000 Will procure

LIMS Budget

20 Report printers $50,000 Purchased LIMS Budget

4 Paper scanners $18,000 Purchased LIMS Budget

200 Uninterruptible power supplies

$20,000 Purchased LIMS Budget

PAGE | 22


55..66 PPRROOJJEECCTT LLOOGGIISSTTIICCSS

Project Member Access Responsibility Contact methods

Vendor Work will be performed onsite as well as remotely. VPN access to development and test environments will be available.

Vendor will be onsite during at least the following phases:

-Section workflow review

-Users Training

- Functional specification review

Email, Phone

Project Team Will work together by phone and email. Meetings will occur in SLD’ library or office of executive Sponsor

Meets as required

SLD section subgroups will be formed during

Email, Phone, Meetings

Steering Committee Will meeting Monthly Meeting

55..66..11 PPRROOJJEECCTT TTEEAAMM TTRRAAIINNIINNGG Resource

Cost Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Bench level user training

$1,500 15 During testing

Laboratory Analyst

LIMS key user training $3,000 24 During Development

DB management and SQL Skills

LIMS Administrator training

$6,000 40 During Development

DB management and SQL Skills

LIMS Administrator XML training

$1,500 Prior to Development

Existing coding and SQL skills

PAGE | 23


66..00 PPRROOJJEECCTT MMAANNAAGGEEMMEENNTT AANNDD CCOONNTTRROOLLSS 66..11 RRIISSKK AANNDD IISSSSUUEE MMAANNAAGGEEMMEENNTT PMBOK©:

Risk: “An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”

Issue: “A point or matter in question or dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.”

Both Risks and Issues can significant impact a project’s success, and both should be handled in similar ways.

66..11..11 RRIISSKK MMAANNAAGGEEMMEENNTT SSTTRRAATTEEGGYY Provide a detailed explanation on the strategy for how risks are identified, analyzed/ quantified, mitigated, reported, escalated and tracked. Include the use of tools such as project management software, forms, and templates. A separate risk management plan may also be developed if needed for the project and included as an Appendix to this document. If that is the case, a high level summary of this plan needs to be included here with the specific reference.

66..11..22 PPRROOJJEECCTT RRIISSKK IIDDEENNTTIIFFIICCAATTIIOONN In the LIMS Project the Project Steering Committee serves as the Risk & Opportunity Management Committee

Risk & Opportunity Management Committee responsibilities: • Approve risk and opportunity management plan. • Encourage the reporting of risks and opportunities • Collect and review risk/opportunity identification forms • Analyze risks and opportunities • Oversee the development of risk/opportunity handling plans • Monitor watch list and risk/opportunity handling plans

66..11..33 PPRROOJJEECCTT RRIISSKK TTRRAACCKKIINNGG AAPPPPRROOAACCHH

Tracking, controlling and reporting the implementation of risk reduction plans through the life cycle

• Output: Prioritized Risk/Opportunity List, Retired Risk/Opportunity List • Responsibility of: Project Risk & Opportunity Management Committee

The Project Risk & Opportunity Management Committee will review the Prioritized Risk/Opportunity List at each meeting. Review will be prioritized by risk/opportunity profile.

PAGE | 24


For the LIMS Project risks and opportunities with a Low profile will be placed on a watch list. Those risks and opportunities will be reviewed for changes at each Project Risk & Opportunity Management Committee meeting.

66..11..44 IISSSSUUEE MMAANNAAGGEEMMEENNTT 6.1.4.1 INTERNAL ISSUE ESCALATION AND RESOLUTION PROCESS

The LIMS project has adopted the following process for managing issues that can be resolved within the Information Technology Services Division or within the project team.

• Solicit potential issues from any project stakeholder, including the project team, steering committee members, project director, and project executive sponsor. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form. The project manager determines whether the problem can be resolved without outside help or whether it should be classified as a formal issue. Formal issues are escalated to the project steering committee for resolution.

• Enter the issue into the Issues Log. The Issues Log contains one entry per issue and is used for tracking purposes.

• Assign the issue to a project team member for investigation. The project manager will also determine who needs to be involved in the decision making process.

• The team member will investigate options that are available to resolve the issue. For each option, he/she will also estimate the impact to the project in terms of budget, schedule and scope.

• The various alternatives and impacts on schedule and budget are documented on the Issues Form. The project manager will take the issue, alternatives and project impact to the people that need to be involved in the issue resolution (from step 4).

• If resolving the issue will involve changing the scope of the project, close the issue now and use the project change management procedures instead to manage the resolution.

• Document the resolution or course of action on the Issues Form. • Document the issue resolution briefly on the Issues Log. • Add the appropriate corrective activities to the work plan and project schedule to ensure

the issue is resolved. • If the resolution of an issue causes the budget or duration of the project to change, the

current project management plan and supporting documents should be updated. Changes to budget and duration of the project must be approved by the project steering committee.

• Communicate issue status and resolutions to project team members and other appropriate stakeholders through the project status report, status meetings and other appropriate communication means.

6.1.4.2 EXTERNAL ISSUE ESCALATION AND RESOLUTION PROCESS

The LIMS project has adopted the following process for managing issues that can be resolved within the Information Technology Services Division or within the project team.

PAGE | 25


• Solicit potential issues from any project stakeholder, including the project team, steering committee members, project director, and project executive sponsor. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form. The project manager determines whether the problem can be resolved without outside help or whether it should be classified as a formal issue. Formal issues are escalated to the project steering committee for resolution.

• Enter the issue into the Issues Log. The Issues Log contains one entry per issue and is used for tracking purposes.

• Assign the issue to a project team member for investigation. • The team member will investigate options that are available to resolve the issue. For each

option, he/she will also estimate the impact to the project in terms of budget, schedule and scope.

• The various alternatives and impacts on schedule and budget are documented on the Issues Form. The project manager will take the issue, alternatives and project impact to the project steering committee to be involved in the issue resolution.

• If resolving the issue will involve changing the scope of the project, close the issue now and use the project change management procedures instead to manage the resolution.

• Document the resolution or course of action on the Issues Form. • Document the issue resolution briefly on the Issues Log. • Add the appropriate corrective activities to the work plan and project schedule to ensure

the issue is resolved. • If the resolution of an issue causes the budget or duration of the project to change, the

current project management plan and supporting documents should be updated. • Communicate issue status and resolutions to project team members and other appropriate

stakeholders through the project status report, status meetings and other appropriate communication means.

66..22 IINNDDEEPPEENNDDEENNTT VVEERRIIFFIICCAATTIIOONN AANNDD VVAALLIIDDAATTIIOONN -- IIVV&&VV Independent Verification and Validation (IV&V) is a risk mitigation strategy designed to provide management with project oversight through an independent evaluation of a project’s product and process quality. The LIMS IV&V approach will includes evaluation of project management practices and key project deliverables for conformance with industry standards and best practices. DOH is currently in the midst of procuring IV&V services. The LIMS project IV&V approach will build on those contractual relationships when they are finalized. IV&V will be in place throughout the project. Bency and Associates has been selected as the IV&V vendor for the project. The specific services that will be requested from the IV&V vendor have and will change as we move from planning to Implementation, but thus far have included:

The IV&V service asked for to date are as follows: IV&V Management Plan Initial and Periodic reviews Initial Risk Assessment

PAGE | 26


Review of As-Is, To-Be and RFP requirements documents A current IV&V vendor contract is currently in the signing phase and ITSD expect it to be in force by the first of December 2007. In this current contract we are receiving the following IV&V services from the IV&V ‘menu’ below:

• Period IV&V Reviews (every other month) • Procurement Planning and Oversight (PO-4 and PO-5) • Project Management (PM-2 and PM-4) • Management Assessment (PM-6 and PM-8) • Project Management (PM-13 & PM-15) • Requirements Management Reports (RM-1 and RM-2) • Operating Environment (OE-1)

66..33..11 CCHHAANNGGEE CCOONNTTRROOLL 6.3.1.1 CHANGE CONTROL PROCESS

Change control will be managed through a Change Control Board (CCB). The CCB will meet monthly to review and prioritize change requests from across SLD according to the following process. Communication will be monthly meetings minutes, a list of current LIMS administrator tasks, and a list of high priority and low priority configuration request as ranked by the CCB.

Configuration change request process

• Requests for configuration changes will be submitted to the CCB

• CCB will prioritize requests as high priority, low priority, or denied

• Prioritized list will be submitted to administrators for implementation

• Request list will be reprioritized during monthly CCB meetings

• New priority lists to be issued after each meeting

• Configuration requests requiring external LIMS consulting will be flagged

• Progress report and priority lists communicated to steering committee monthly

PAGE | 27


6.3.1.2 CHANGE CONTROL BOARD (CCB)

CCB Members Twila Kunde SLD Deputy Director

Danny Gray Lead LIMS administrator

Tim Elsbrock LIMS Project Manager

Debra Horensky Biology Bureau Chief

Phil Adams Chemistry Bureau Chief

66..44 PPRROOJJEECCTT BBUUDDGGEETT MMAANNAAGGEEMMEENNTT

Description FY06 FY07 FY08 FY09

PAGE | 28


Staff - Internal

$35,000 $90,000 $90,000

Consulting Services

$39,829 $80,171 $318,600 $525,280

Hardware $305,106

Software $286,000 $110,000

T

TOOTTAALL $39,829 $115,171 $999,706 $725,280

66..44..11 BBUUDDGGEETT TTRRAACCKKIINNGG It is the responsibility of the project manager to manage the project budget. The initial project budget is built during the planning phase of the project. The project manager will track expenditures against the project budget to ensure that the project remains within budget. Issues, risk mitigation, or scope changes that negatively impact the project budget will be brought to the attention of the project steering committee. The project budget will be reviewed at each project steering committee meeting.

66..55..11 CCOOMMMMUUNNIICCAATTIIOONN MMAATTRRIIXX

66..55..22 SSTTAATTUUSS MMEEEETTIINNGGSS Monthly Steering Committee Meeting

Project Team meetings as required

During implementation the frequency will increase to facilitate revision cycle

66..55..33 PPRROOJJEECCTT SSTTAATTUUSS RREEPPOORRTTSS

• Monthly status reports given during Steering Committee meetings

• DoIT monthly status report

• ITSD weekly status report

66..66 PPEERRFFOORRMMAANNCCEE MMEEAASSUURREEMMEENNTT ((PPRROOJJEECCTT MMEETTRRIICCSS)) The Project Manager and Executive Sponsor define the project metrics that will be used to control the project. Each project will need to have an established metrics program. Metrics are collected for measuring the progress of a project against its planned budget, schedule, resource usage, and error rates, and of establishing a historical database, which will aid in planning and forecasting future projects. At a minimum metrics must be established for time (schedule), cost (budget) and quality.

PAGE | 29


66..66..11 BBAASSEELLIINNEESS

Project Area Category Measure

Scope Objectives Project remains within scope of project charter

Schedule Timelines Project is proceeding on estimated timeline, reasons for schedule slips are documented

Budget Financial Project remains within budget allocations

66..77 QQUUAALLIITTYY OOBBJJEECCTTIIVVEESS AANNDD CCOONNTTRROOLL Quality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, quality assurance, quality control, and quality improvement, within the quality system. If a separate Quality Plan is used, include a high level summary in this document and refer to the appropriate appendix.

66..77..11 QQUUAALLIITTYY SSTTAANNDDAARRDDSS Describe the agency, industry or regulatory project performance standards that will be followed and assessed by the project. These quality standards will be used to assess whether the quality objectives were achieved.

Identify each of the project quality standards that are directly related to the project and not to the performance of the actual product and/or service. For each quality standard, identify the tracking tool or measure such as number of project reviews or Project Status.

No. Quality Standard Tracking Tool or Measure

1 Health Insurance Portability and Accountability Act of 1996 (160.103) This specifies a series of administrative, technical, and physical security procedures for covered entities to use to assure the confidentiality of electronic protected health information.

LIMS Compliance

PAGE | 30


2 Clinical Laboratory Improvement Amendment, 1988 The purpose of this amendment is to ensure quality laboratory testing through the regulation of all human laboratory testing for the purpose of diagnosing or treating a disease, illness, or assessment of health of human beings.

LIMS Compliance

3 United States Environmental Protection Agency Manual for the Certification of Laboratories Analyzing drinking Water, 5th Ed, EPA 815-R-05-004, Jan 2005. Certification of laboratories that analyze and certify drinking water systems.

LIMS Compliance

4 American Board of Forensic Toxicologists Mission is to establish and enhance voluntary standards for the practice of forensic toxicology and for the examination and recognition of scientists and laboratories providing forensic toxicology services.

LIMS Compliance

5 US Food and Drug Administration Grade “A” Pasteurized Milk Ordinance, Appendix N 2001 Revision, May 15, 2002 The basic standard used in the voluntary Cooperative State-PHS/FDA Program for the Certification of Interstate Milk Shipments, a program participated in by all fifty (50) States, the District of Columbia and U.S. Trust Territories.

LIMS Compliance

6 New Mexico Radiation Control Bureau Sections 74-3-1 through 74-3-16 NMSA1978, 20.3.3 NMAC Monitor inventory, usage and disposal of radioisotopes.

LIMS Compliance

7 US DOJ Drug Enforcement Administration Sections 304 and 1008 of 21USC824 and 958 of the controlled Substances Act of 1970. Monitor inventory of controlled substances

LIMS Compliance

8 DHHS Select Agents and Toxin 42 CFR Parts 72 and 73, Possession, Use, and Transfer of Select Agents and Toxins; Final Rule Monitor inventory, use, and disposal of select agents.

LIMS Compliance

PAGE | 31


66..77..22 AAGGEENNCCYY//CCUUSSTTOOMMEERR SSAATTIISSFFAACCTTIIOONN Examples:

Areas of feedback When How Often

Agency awareness Steering Committee Monthly

Quality of communications Steering Committee Monthly

Manages project tasks Steering Committee, ITSD meetings

Monthly

Productive Meetings Steering Committee, 1:1 Monthly

66..77..33 PPRROODDUUCCTT DDEELLIIVVEERRAABBLLEE AACCCCEEPPTTAANNCCEE PPRROOCCEESSSS

Deliverable Final Approval Process Customer Acceptance Criteria

User Acceptance of Section 1 LIMS is deployed into section for testing, routines are used in production, LIMS administrators have configured external communications, equipment interfaces. LIMS is deemed satisfactory in current state so letter of acceptance is written to vendor.

Each section within SLD will have their own criteria, but some guidelines are: LIMS manages section workflow, Section specific tests are in LIMS, Section equipment priority interface list addresses, section external Comm. list addressed, LIMS is in production and working to expectation of section analysts, Administrators are in section working with/training users.

User Acceptance of Section 2 Repeat above Repeat above

User Acceptance of Section 3 Repeat above Repeat above

Final User Acceptance of LIMS

Once the LIMS is functioning across SLD, a review of unmet requirements is needed to decide if further configuration is warranted, or if requirement was inaccurate. Final review of documentation, near term configuration expectations as result of initial implementation, and overall usability and user training of system will be reviewed by steering committee.

SLD will accept LIMS system as delivered via written letter to vendor.

PAGE | 32


66..88 CCOONNFFIIGGUURRAATTIIOONN MMAANNAAGGEEMMEENNTT Configuration Management determines how project information (files, reports, designs, memos, documents, etc.) will be managed (tracked, approved, stored, secured, accessed, version control, etc.) and owned by (e.g., Agency managing the project or the Customer). Standards and team awareness are critical.

66..88..11 VVEERRSSIIOONN CCOONNTTRROOLL Project documents will be identified by a version number, starting at one and increasing by one for each release. The version number will appear on the first page of the document and within the footer of each page. Documentation will be identified as follows:

• a release number (and a revision letter if in draft);

• the original draft shall be Version 0.A;

• subsequent drafts shall be Version 0.B, Version 0.C etc;

• the accepted and issued document is Release 1.0;

• subsequent changes in draft form become Version 1.0A, 1.0B etc; and

• the accepted and issued second version becomes Version 1.1 or Version 2.0, as determined by the author based on the magnitude of the changes (minor or major).

Project documents that are based upon templates owned and managed by external agencies will not follow the version control requirements above. Instead, those documents will utilize the version control process defined within each document.

66..88..22 PPRROOJJEECCTT RREEPPOOSSIITTOORRYY ((PPRROOJJEECCTT LLIIBBRRAARRYY)) The LIMS project uses an electronic document library within a Microsoft SharePoint site. All project documents, deliverables, and supporting information is available within this site. All project team members have access to the site.

66..99 PPRROOCCUURREEMMEENNTT MMAANNAAGGEEMMEENNTT PPLLAANN All procurement activities within the LIMS project will follow the State of New Mexico procurement code, General Services Department State Purchasing Division rules, Department of Finance and Administration rules, Department of Information Technology rules, and the Department of Health procurement guidelines. The LIMS project has three major procurement activities. The first procurement activity is the issuance of a RFP for the acquisition and implementation of a LIMS system. The second procurement is a professional services contract for project consulting and implementation services. The third procurement is for necessary hardware and software for the LIMS system.

PAGE | 33


PAGE | 34

77.. 00 PPRROOJJEECCTT CCLLOOSSEE It is the policy of DOH that all IT projects will be proposed, approved, planned and implemented in accordance with a project management methodology.

Once project activities have concluded the project will be closed by finalizing all deliverables, formally accepting the project products, compiling lessons learned, releasing project assets and obtaining sign off on the project from the sponsor. The procedure for closing a project follows:

A. Post Project Review

1. Feedback solicitation a. Product effectiveness b. Triple constraint (Scope, Budget, Schedule) management c. Risk management d. Acceptance management e. Issues Management f. Transition to operations g. Performance of performing organization h. Performance of project team i. Lessons learned (stakeholders)

2. Project Assessment 3. Preparation of the Post Project Report 4. Provide Project Team Performance Feedback (ITSD Personal only).

77..11 AADDMMIINNIISSTTRRAATTIIVVEE CCLLOOSSEE • Archive Project Information • Project description/definition documents such as the Project Charter, Project Proposal and the

Project Management Plan. • Project Schedules – retain all copies electronically, but only include the baseline and final

schedule in the hardcopy repository. • Project financials • Project scope changes and change log • Project Status Reports • Issues log and details (open and resolved) • Project Deliverable Approvals (email, meeting minutes, original signatures, etc.) • Risk Management Matrix • Correspondence, including any pivotal or decision-making memos, letters, e-mail, etc.

o Meeting minutes, results and/or actions o Final project approval form, with original signatures

• Post-project report • State DoIT project closure report • Lessons learned

77..22 CCOONNTTRRAACCTT CCLLOOSSEE Contract Closure – Verification that deliverables have come in and are accepted. Assure that final invoices have come in, approve payments and send the following in for processing.

• Contract file

• Deliverable acceptance