[INSERT PROJECT NAME]€¦ · Web viewMarilyn Hill, Dep. Cab Sec. Pamelya Herndon, Dep. Cab. Sec....

G GENERALENERAL S SERVICESERVICES DEPARTMENTDEPARTMENT

EEPPROCUREMENTROCUREMENT P PROJECTROJECT

PROJECT MANAGEMENT PLAN PROJECT MANAGEMENT PLAN (PMP)(PMP)

EXECUTIVE SPONSOR

ARTURO JARAMILLO,

GENERAL SERVICES DEPARTMENT CABINET SECRETARY

BUSINESS OWNER

ROSS BOOM, SPD DEPUTY DIRECTOR

PROJECT MANAGER

KEITH CAMPBELL, CONSULTANT, ORACLE, INC.

GSD CHIEF INFORMATION OFFICER

Karen Baltzley

ORIGINAL PLAN DATE: DECEMBER 22, 2008

REVISION DATE: OCTOBER 12, 2009REVISION: 2.4

PROJECT MANAGEMENT PLAN FOR EPROCUREMENT PROJECT

REVISION HISTORY............................................................................................................................................ IV

1.0 PROJECT OVERVIEW...................................................................................................................................... 5

1.1 Executive Summary- rationale for the Project...................................................................................................5Goals of the Project.................................................................................................................................................81.2 funding and sources..........................................................................................................................................91.3 constraints.......................................................................................................................................................131.4 dependencies..................................................................................................................................................141.5 ASSUMPTIONS.................................................................................................................................................141.6 Project Risks Identified..................................................................................................................................15Risk 1: Inadequate Funding...................................................................................................................................15Risk 2: Inadequate personnel................................................................................................................................16Risk 3: Outsourced Vendor / Solution...................................................................................................................16Risk 4: Inconsistencies of Procurement Transactions between modules..............................................................17Risk 5: Ineffective Training for Purchasing staff.....................................................................................................17Risk 6: Loss of Project Manager under POD Professional Services Contract..........................................................18

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE...........................................................................19

2.1 Stakeholders....................................................................................................................................................192.2 Project Governance Structure.........................................................................................................................23

2.2.1 Describe the organizational structure – Org Chart...................................................................................232.2.2 Describe the role and members of the project steering committee.........................................................232.2.3 Organizational Boundaries, interfaces and responsibilities.....................................................................24

2.3 Executive Reporting.........................................................................................................................................24

3.0 SCOPE......................................................................................................................................................... 25

3.1 Project Objectives...........................................................................................................................................253.1.1 Business Objectives..................................................................................................................................253.1.2 Technical Objectives................................................................................................................................26

3.2 Project exclusions............................................................................................................................................263.3 Critical Success Factors....................................................................................................................................26

4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................28

4.1 Project Management Life Cycle.......................................................................................................................284.1.1 Project Management Deliverables...........................................................................................................314.1.2 Deliverable Approval Authority Designations..........................................................................................414.1.3 Deliverable Acceptance Procedure...........................................................................................................46

4.2 PRODUCT LIFE CYCLE.......................................................................................................................................474.2.1 Technical Strategy...................................................................................................................................484.2.2 Project and Product Development Deliverables.......................................................................................494.2.3 Deliverable Approval Authority Designations..........................................................................................51Note, the deliverbales in the tables above will be updated at the completion of the Planning Phase activities.......................................................................................................................................................................... 554.2.4 Deliverable Acceptance Procedure...........................................................................................................55

5.0 PROJECT WORK........................................................................................................................................... 56

5.1 Work Breakdown Structure (WBS)..................................................................................................................565.2 Schedule allocation -Project Timeline.............................................................................................................655.3 Project Budget.................................................................................................................................................685.4 Project Team...................................................................................................................................................69

5.4.1 Project Team Organizational Structure....................................................................................................695.4.2 Project Team Roles and Responsibilities..................................................................................................70

I


5.5 STAFF PLANNING AND Resource ACQUISITION...............................................................................................755.5.1 Project Staff.............................................................................................................................................815.5.2 Non-Personnel resources.........................................................................................................................85

5.6 PROJECT LOGISTICS.........................................................................................................................................865.6.1 Project Team Training..............................................................................................................................87

6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................87

6.1 Risk and issue Management............................................................................................................................876.1.1 Risk Management Strategy......................................................................................................................886.1.2 Project Risk Identification........................................................................................................................886.1.3 Project Risk Mitigation Approach............................................................................................................886.1.4 Risk Reporting and Escalation Strategy...................................................................................................886.1.5 Project Risk Tracking Approach................................................................................................................896.1.6 ISSUE MANAGEMENT..............................................................................................................................89

6.2 INDEPENDENT Verification And Validation - Iv&V...........................................................................................916.3 Scope Management Plan.................................................................................................................................91

6.3.1 Change Control........................................................................................................................................916.4 Project Budget Management..........................................................................................................................92

6.4.1 Budget Tracking.......................................................................................................................................926.5 Communication Plan.......................................................................................................................................92

6.5.1 Communication Matrix............................................................................................................................936.5.2 Status Meetings.......................................................................................................................................966.5.3 Project Status Reports..............................................................................................................................96

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................966.6.1 Baselines..................................................................................................................................................966.6.2 Metrics Library.........................................................................................................................................97

6.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................976.7.1 quality Standards.....................................................................................................................................976.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................976.7.3 Agency/Customer Satisfaction.................................................................................................................986.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................98

6.8 CONFIGURATION MANAGEMENT...................................................................................................................996.8.1 Version Control......................................................................................................................................1006.8.2 Project Repository (Project Library).......................................................................................................100

6.9 PROCUREMENT MANAGEMENT PLAN..........................................................................................................100

7. 0 PROJECT CLOSE......................................................................................................................................... 101

7.1 Administrative Close.................................................................................................................................1017.2 Contract Close...........................................................................................................................................101

ATTACHMENTS................................................................................................................................................ 102

Attachment A: Project Schedule with Milestones and Tasks..........................................................................103Attachment A: Project Schedule with Milestones and Tasks..........................................................................103Attachment B: Risk Assessment Report.........................................................................................................104

REVISION HISTORY.......................................................................................................................................... 106

RATIONALE -PROJECT RISK ASSESSMENT REPORT............................................................................................108

Department of information technology requirement.........................................................................................108Risk Assessment and Risk management..............................................................................................................108

RISK EVALUATION FOR THIS PROJECT..............................................................................................................109

IMPACT RISK................................................................................................................................................... 109

II


Project Organization Risks...................................................................................................................................110Requirement Risks...............................................................................................................................................112Technical Risks....................................................................................................................................................113Planning Risks......................................................................................................................................................114

INITIAL RISKS IDENTIFIED IN PROJECT CHARTER AND/OR PROJECT MANAGEMENT PLAN.................................114

Instructions for completing the risk identification table.....................................................................................114Risk 1: Inadequate Funding.................................................................................................................................115Risk 2: Inadequate personnel..............................................................................................................................115Risk 3: Outsourced Vendor / Solution.................................................................................................................116Risk 4: Inconsistencies of Procurement Transactions between modules............................................................116Risk 5: Ineffective training for Purchasing Staff...................................................................................................117Risk 6: Loss of Project Manager under POD Professional Services Contract........................................................117

ATTACHED PROJECT RISK LOG – AFTER INITIAL ASSESSMENT...........................................................................118

RISK CALCULATION EXAMPLE.......................................................................................................................... 118

eProcurment Project Risk Assessment and Rating..........................................................................................119Attachment C: Risk and Issue Log.................................................................................................................121Attachment D: Change Request Log..............................................................................................................124Attachment E: GSD Memorandum of Understanding for eProcurement.......................................................127Attachment F: Project forms/Templates.......................................................................................................128Attachment G: Project Budget.....................................................................................................................134Attachment H: eProcurement Project Library...............................................................................................135Attachment I: eProc Project Acronyms..........................................................................................................136Attachment J: Project Management Definitions..........................................................................................137Attachment K: eProcurement Project Test Strategy......................................................................................143

REVISION HISTORY.............................................................................................................................................. 1

1 INTRODUCTION.......................................................................................................................................... 3

2 TEST OBJECTIVES........................................................................................................................................ 3

3 IDENTIFY TEST TYPES.................................................................................................................................. 3

4 SCOPE OF TESTING..................................................................................................................................... 4

5 TEST PREPARATION AND EXECUTION PROCESS...........................................................................................5

5.1 Test Preparation........................................................................................................................................55.2 Test Execution...........................................................................................................................................6

6 TEST DATA MANAGEMENT......................................................................................................................... 7

7 Testing attachments – planning and execution..................................................................................................8

III


REVISION HISTORYREVISION HISTORY

RREVISIONEVISION N NUMBERUMBER DDATEATE CCOMMENTOMMENT

July 27, 2007 DoIT Project Management Office Revision

1.0 December 22, 2008 1st DRAFT of Initial PMP for Team review and input

1.1 January 26, 2009 Revised per Project Team review and input

1.1.1 January 30, 2009 Submitted as Proj Mgmt Del. 1 for final acceptance

1.1.2 February 6, 2009 Revised per Project Team

1.1.3 February 12, 2009 Revised per GSD, SPD, DFA input



2.0 March 31, 2009 Updated PMP – Implementation Phase

2.1 May 05, 2009 Updated PMP – Resources and Risks updated

2.2 August 6, 2009 Updated PMP – Resources, Training plan testing plan and Risks updated

2.3 September 30, 2009 Updated PMP – Deliverables, Testing

2.4 October 13, 2009 Updated PMP – Project go live updates for Phase I and eProcurement additions for Phase II

IV

1.0 PROJECT OVERVIEW1.0 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The scope of this project will include reviewing and documenting the current SHARE system procurement functionality and state of implementation; identify the functionality of the uninstalled SHARE modules for impact to SPD procurement and perform analysis of the SPD business process. The data will support the gap-analysis and identification of additional modules and or modifications to the current procurement process to achieve an efficient system. The scope will include development of priorities and a workflow design to configure and implement Strategic Sourcing and e-Procurement module functionality to automate business process requirements for Solicitation Release and Vendor Notification processing.

This project will enable State Purchasing to follow consistent, controlled, automated processes and provide workflow tracking as well as e-procurement functionality for state agencies and other public entities. Timely communications between SPD, vendors and Agencies will be facilitated and access to secured and accurate data will be significantly improved. Error reduction and quality control are critical need factors of the system as is the ability to assemble historical purchasing activities to support trend analysis and buying patterns. Effective Spend Management will provide higher value to the State for each dollar spent.

The implementation of SHARE financials for the State of New Mexico and the subsequent departure of State Purchasing Division of the costly IDMS mainframe procurement applications have had a very large negative impact on the Divisions tracking ability, work flow and automation of business processes of the State Purchasing Division.

The Division reverted back to manual processing in order to meet the statutory and business requirements it is responsible for. Those areas most critically impacted are the Invitation to Bid process, Request for Proposal process, contract management and administration, vendor registration, management, internal tracking and assignment of workflow. The Division is in desperate need of automation and access to data particularly for document management to support public record and public review of procurement documents, detailed purchasing reports to support strategic sourcing efforts, bid tabulations, protest response and management, and review and approval of exception purchases (i.e., sole source, GSA requests and emergency requisitions).

There is business opportunity to enhance and meet critical needs through the implementation of a comprehensive eProcurement and Strategic Sourcing automated solution. The immediate opportunities are in the increased efficiency and accuracy of work, the increased professionalism of the products produced, the reassignment of staff to analytical, more value-added work than the current manual process requires and promotes. The overarching achievement will be an effective, efficient purchasing operation resulting in reduced waste, appropriate and effective use

of public funds, streamlined and cooperative interactions with New Mexico businesses and an increase of accountability across state government.

This project will build upon the existing infrastructure and knowledge base of the State of New Mexico SHARE system by implementing State owned PeopleSoft e-procurement application and Strategic Sourcing modules where effective that will enhance and automate the State Purchasing Division (SPD). This will enable SPD to implement and follow consistent, controlled, accountable, efficient processes and provide Strategic Sourcing capabilities to all state agencies utilizing eSourcing methodologies and practices.

The Division’s plan is to leverage the existing work done to align the business processes from the SHARE implementation and the internal SPD business, functional and project management knowledge and skills in collaboration with external support to complete this implementation. The outcomes will include procurement savings through the use of Strategic Sourcing and eProcurement as defined above.

We plan to utilize outside contract vendors for those areas we feel we have limited knowledge or resources including: customization of the software if required, specific high-level Oracle database administrator skills for sizing, tuning, configuration and implementation, IV&V oversight and guidance, DoIT oversight and guidance as well as interfacing for actual Data Center migration.

Existing SPD/GSD staff has significant functional experience in the PeopleSoft procurement system that will compliment and complete the required business and functional skills required to complete this project successfully.

The Division envisions and fully supports changes to business processes as well as organizational and management shifts in order to realize the greatest return on investment in this project.

As a follow up from version 2.4 (October 13, 2009), this eProcurement project has gone live with the Optimization A capabilities. These capabilities were noted as recommendations during the Health check (initiation phase) and further detailed after as part of the Project Planning Phase. The State went live on Friday, October 9, 2009 with the Option A Capabilities.

As a review, the health check recommended a roadmap as follows:

Implement Optimization A

Implement Optimization B items

Upgrade the SHARE Application

Implement eProcurement

6

Implement Strategic Sourcing

Implement Supplier Contract Management

Since the upgrade of the SHARE Application from release 8.8 to 9.1 will not be viable for FY11, the Team (as of October, 2009) has looked at alternative next steps and has considered for following 3 options:

1) Implement the Optimize B Capabilities

2) Implement eProcurement at a set of Pilot Agencies

3) Implement Strategic Sourcing at SPD

The team took a look at system capabilities, module demands and the system requirements listing generated by the State before the Health check. Based on this set of analysis, the team decided for a scope change to pursue the implementation of eProcurement at a set of State Pilot Agencies. The team will be going for certification of funds for Planning Phase activities related to implementing eProcurement in November of 2009.

The Implementation of the eProcurement module is designed to address the following goals: Implementing the eProcurement Module will help improve business processes in terms of

efficiency and effectiveness Implementing eProcurement will address yet to be completed Health check

recommendations Implementing eProcurement will address and resolve Audit findings Phase II will maintain continuity and momentum gained and achieved by the successful

implementaiton of Phase I Workflows and delivered on line inquiry (reporting) capabilities will provide further

transparency and consistency in metric reporting

Workflows and supporting business processes delivered with eProcurement will enhance internal controls related to procurement activities

7

GOALS OF THE PROJECTGOALS OF THE PROJECT Eliminate and or reduce current manual work overload

Significantly improve efficiency of procurement process

Enable strategic sourcing through the process of capturing spend patterns and product usage across the state.

Allow access and use/improve efficiency of state agencies as well as local public body procurement processes

Reengineer SPD business processes to maximize utilization and benefits of an electronic procurement system

Provide automation to two of the current intensive manual business processes; Solicitation Release and Vendor Notification

Conduct an Oracle Health Check Assessment to define current state of procurement software implementation and document final business requirements.

The Oracle Health Assessment Scope and Deliverables are;

Scope:

1. Perform an in-depth discovery of SPD current and planned business processes (with particular attention paid to two workflows provided by the State which shows Vendor Notification and Solicitation Release processes). This will include an assessment of the Application with respect to business process flows, data volumes, application configuration setup, interfaces, security, reporting, and customizations;

2. Conduct on-site interviews with State key personnel to further identify issues related to use of the Application;

3. Identify the basis for SPD planned business process changes;

4. Provide recommendations regarding the use of the eProcurement and Strategic Services Application based on current issues related to the Application and planned business process changes (especially the business processes related to the workflows shared by the State Purchasing Division with Oracle); and

5. Document the findings from the services in the form of a Health Check Assessment Report. This finding report will also contain a budgetary estimate to implement:

8

A. eProcurement and Strategic Sourcing – an estimate of what it would take to implement the two modules to meet the business processes covered by the workflows that the State shared with Oracle Corporation

B. Finish implementing the proposed suite of Purchasing modules in the States next budget year.

C. Document current implementation state of the e-Procurement and Strategic Sourcing modules in the SHARE system

Deliverables:

1. Perform Health Check Assessment1.1 Contractor shall:

-provide a documented assessment of the State of New Mexico (SoNM)current use of the PeopleSoft procurement applications,-provide written recommendations of how the SoNM can implement thepurchased PeopleSoft applications to achieve GSD/SPD written goals andrequirements for eProcurement and strategic sourcing,-provide written recommendations as to how SoNM can best implementother PeopleSoft supply chain applications in phased pieces to furtherachieve the SoNM eProcurement goals and requirements.

2. Provide Budgetary Estimates and Implementation Strategies2.1 Contractor shall:

-provide a phased approach methodology with written documentation,including cost estimates and implementation strategies for what it wouldtake to implement the eProcurement and Strategic Sourcing modules tomeet the business processes covered by the workflows identified in item 1.1above,-provide a written estimate to complete the implementation of the proposedsuite of Supplier Relationship Management (SRM) modules in the SoNM’sfuture budget years.

1.2 FUNDING AND SOURCES1.2 FUNDING AND SOURCESFunding and Sources for Phase I

SOURCESOURCE AMOUNTAMOUNT ASSOCIATED ASSOCIATED RESTRICTIONSRESTRICTIONS

APPROVERSAPPROVERS

Laws 2008, Ch 3, Sec 7, item 10 – includes $500.0 “for strategic sourcing and electronic

$500,000.00 DFA has oversight of funds.

Executive Steering Committee, DFA Budget Control

9

procurement configuration for the general services

TOTAL FUNDS $500,000.00

Funding and Sources for Phase II

SOURCESOURCE AMOUNTAMOUNT ASSOCIATED ASSOCIATED RESTRICTIONSRESTRICTIONS

APPROVERSAPPROVERS

Laws 2009, Chapter 3, Sec. 7 – Data Processing Appropriation includes $935,000 that is “reappropriated to the Department of Information Technology (DoIT) for incremenetal license fees and to address the critical issues with the Statewide Human Resources, Accoutnging and Management Reporting Systems.”

$435,000 DoIT has oversight of the funds

Executive Steering Committee, DFA Budget Control

TOTAL FUNDS $435,000

Phase I – Certification Dates and Amounts by Project Phase

PHASES PLANNED CERTIFICATION DATE AMOUNT

Initiating December. 12, 2008 Certified $92,000

Planning Feb 25 – April 22, 2009: Total request

(PM $115.0, Oracle Professional Services $30.)

$ 145,000

10

eProcurement Project Assumptions:

o Will be based on Health Check recommendations

o There will be multiple planning and implementation phases over multiple funding years.

o This will regard the first phase planning phase and utilize the initial remaining $408K and existing resources.

o This scope of work will be dependent on the $408K still being available.)

Implementing April 23 – September 30, 2009

(Oracle Professional Services $247.0, IV&V $8.0, Contingency $8.0)

(Same assumptions as above)

$263,000

Closing October 1 - 31, 2009


TOTAL $500,000

Phase II – Certification Dates and Amounts by Project Phase

PHASES PLANNED CERTIFICATION DATE AMOUNT

Initiating December. 12, 2008 Certified $0.00

Planning October 28, 2009: Total request

eProcurement Project Assumptions:

o Will be based on Health Check

$36,000

11

recommendations

o Will Implement eProcurement at a Pilot Agencies, Develop a Cookbook and test cookbook for additional rollouts to subsiquent agencies.

o This scope of work will be dependent on the funding still being available.

Implementing (including Project Management)

Plan to Start in February 2010 – scope TBD based on Planning

TBD based on Planning

Closing Estimated July 2010


TBD based on Planning

Rollouts TBD based on Planning after closeout of First Implementation

TBD Based on Planning

TOTAL $435,000

Budget figures are subject to change after Oracle conducts Health Assessment and develops a design document based on their findings of current software implementation status and final SPD business requirements.

Phase I – Project Budget Figures by Item

ITEM ESTIMATE

Oracle Professional Services Oracle $319,000

IV&V $8,000

Project Manager 1,736 hrs @ $95/hr $165,000

Hardware $ 0

Software $ 0

Support Annual Software Maintenance $ being paid by DFA/SHARE

12

Contingency 3% of $500,000 $8,000

TOTAL BUDGET Amount Less Agency Internal Staff

$500,000

Phase II – Project Budget Figures by Item

ITEM ESTIMATE

Project Management and Professional Services

Oracle – note amounts to the right are estimated to be determined by planning and are inclusive of Planning Phase Activities.

$300,000 – 350,000

IV&V $8,000

Hardware $ 0

Software $ 0


Provision / leftover if needed for additional rollouts

This is really leftover from the $435,000 amount

113,950 – 63,950

Contingency 3% of $435,000 $13,050


$435,000

1.3 CONSTRAINTS1.3 CONSTRAINTSConstraints are factors that restrict the project by scope, resource, or schedule.

13

NUMBERNUMBER DESCRIPTIONDESCRIPTION

1 System must be integrated with other SHARE/PeopleSoft modules; including the financial system module(s)

2 Long-term approach to application architecture and implementation plan is necessary to allow for SPD required functionality to be achieved on an incremental basis. (i.e. there will be additional phases expanding to include on-line bidding/RFP handling and communication/collaboration)

3 Customization of PeopleSoft modules will be avoided by adapting SPD business processes to greatest extent possible.

1.4 DEPENDENCIES1.4 DEPENDENCIESTypes include the following and should be associated with each dependency listed.

M- 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

NUMBENUMBERR

DESCRIPTIONDESCRIPTION TYPE M,D,ETYPE M,D,E

1 Module training by SPD staff is completed prior to close of implementation. Training for any subsequent Implementation will be scheduled commensurate with the needs.

D

2 Existing SHARE ERP System hardware will accommodate the processing requirements of additional procurement modules to be configured and implemented on the SHARE system

M

3 The existing core network bandwidth will meet the need. M

14

1.5 1.5 ASSUMPTIONSASSUMPTIONSAssumptions are planning factors that, for planning purposes, will be considered true, real, or certain.


1 State Purchasing can continue to offer state-wide agreements to user agencies

2 Handling of financial transactions are consistent between the procurement modules and the SHARE financial system

3 Revision levels of PeopleSoft procurement modules will be compatible with the current revision levels of the already implemented PeopleSoft Financial system

4 Added functionality in the SHARE Financials systems will not adversely impact the network performance.

5 System hardware will support the added growth in processing and data storage associated with the new modules that will become functional

6 Electronic notification functionality will become enabled to support approvals/releases

7 Staffing levels (for GSD IT support, DFA Financials Team, and DoIT Operations/Network) are assigned as resources to support this procurement implementation effort

8 The Procurement modules of the SHARE ERP system will allow access by outside vendors, Local Public Bodies. Visibility of these agreements must be made available to LPB’s. In addition, LPB’s require access to vendor preference data and LPB’s can utilize statewide pricing agreements.

1.6 PROJECT RISKS IDENTIFIED1.6 PROJECT RISKS IDENTIFIED In this section identify and describe how each risk will be managed. Include the steps that will

15

be taken to maximize activity that will result in minimizing probability and impact of each risk.

See Attachment B: Risk Assessment

RISK 1: INADEQUATE FUNDINGRISK 1: INADEQUATE FUNDING Description - Insufficient funds appropriated to support this project;

Probability: POSSIBLE Impact: LOW 1) May be forced to implement procurement functionality in a phased manner. 2) SPD may be unable to meet statutory requirements, 3) customer agency needs may not be completely met, and 4) procurement efficiency will be negatively impacted

Mitigation Strategy: Need to prioritize required functionality and focus efforts on highest impact areas. Contingency Plan: Worst case, status quo continues; Most likely case, implement a subset of functionality. SPD may be required to assign personnel to cover gaps in system/tool availability

RISK 2: INADEQUATE PERSONNELRISK 2: INADEQUATE PERSONNELDescription- Lack of adequate personnel to support the eProc Project effort.

Probability: POSSIBLE Impact: LOW that schedules will be delayed, costs may increase and project may not receive the thought and testing required for smooth transition into production/implementation Surprises may occur during the initial go-live period

Mitigation Strategy: Ensure adequate trained personnel are enlisted to support the effort up front. Realistically develop schedule and identify potential outsource opportunities such as Project Management, consultants, software configuration, etc.Contingency Plan: Identify scope priorities and schedule slippage opportunities. Monitor closely the workload and personnel assignments. Utilize outside resources if budget will accommodate

RISK 3: OUTSOURCED VENDOR / SOLUTIONRISK 3: OUTSOURCED VENDOR / SOLUTION

16

Description Outsourcing project implementation

Probability: EXPECTED Impact: LOW System may not fully meet needs. Costs are increased.

Mitigation Strategy: Ensure dedicated Project Manager resource. Must closely monitor and manage outside implementation team. Perform regular validation reviews to ensure implementation assumptions used by third party are consistent with user organization(s) as well as track progress to identify issues that may cause schedule delays and cost overruns. If schedules start to slip, apply additional resources and/or re-focus vendor priorities. Monitor cost incurrence closely. Structure the third party agreement to incentivize schedule adherence, cost control, and resultant system performance.Contingency Plan: Monitor situation closely and utilize all functionality available. Worst case: Status quo continues, unable to fully meet statutory requirements, serve customers, and procurement bottleneck. SPD may be required to assign personnel to cover gaps in system/tool availability

RISK 4: INCONSISTENCIES OF PROCUREMENT TRANSACTIONS RISK 4: INCONSISTENCIES OF PROCUREMENT TRANSACTIONS BETWEEN MODULESBETWEEN MODULES

Description Financial handling of procurement transactions in current SHARE system may have deviated from the “boiler” assumptions that are built into the procurement modules

Probability: POSSIBLE Impact: LOW that Procurement transactions may be tracked in the financial system inconsistently and/or incorrectly

Mitigation Strategy: Rely on Health Check to identify areas deviated from the boiler plate assumptions and make recommendations for handling. Substantial testing of the procurement (related) modules of PeopleSoft for financial handling/results will be necessary to identify if problems exist with current financial flows and those built into the modulesContingency Plan: In event financial transactions are inconsistent between the modules, delay of migration to the production environment may be necessary until such time resolution and consistency are available. SPD may be required to assign personnel to cover gaps in system/tool availability

RISK 5: INEFFECTIVE TRAINING FOR PURCHASING STAFFRISK 5: INEFFECTIVE TRAINING FOR PURCHASING STAFF

17

Description – Inadequate or ineffective SHARE training for SPD and Agency Staff.

Probability: POSSIBLE Impact: LOW Improvements and enhancements to current PeopleSoft (SHARE) system purchasing functionality will not be realized. Transition or change management will be more difficult because of user errors. Increased User trouble tickets and demand for SHARE technical support staff.

Mitigation Strategy: Identify Training needs, end users who need training. Standardize procedures for all Central Purchasing and Agency Purchasing end users. Identify “Super Users” from the Central Purchasing, Agency and Tech Support User community who will be trained. Engage “Super Users” with the eProc Team in developing of comprehensive training plan to provide training on Purchasing modules, functions and procedures. Ask Oracle to include recommendations for training specific to their recommendations for improvements and road forward for the People Soft (SHARE) system and consider contracting Oracle Trainers to provide specific training for State of NM Purchasing “Super Users” and others, as possible.

Update and utilize existing UPK Training facilities for training end users.

Contingency Plan: Identify Super Users at Central Purchasing and each Agency who will be responsible to train end users at their location or unit. These Super Users will also be responsible for providing first level End user support on Purchasing functions and procedures to end users in their location. Develop Training materials and webinars and make available to Purchasing and Agency end users.

RISK 6: LOSS OF PROJECT MANAGER UNDER POD PROFESSIONAL RISK 6: LOSS OF PROJECT MANAGER UNDER POD PROFESSIONAL SERVICES CONTRACTSERVICES CONTRACT

Loss of Project Manager under POD Professional Services Contract

Probability: CERTAIN Impact: HIGH

Mitigation Strategy: Contract with Oracle to provide Project Management planning and oversight for the testing and training phases of the project. It is too late in the project life cycle to bring in another project manager who is not already familiar with the project.

Contingency Plan: Ensure that e-Procurement Project Team works with Oracle to manage balance of the project and begin planning for the next phase -- Optimization B

18

Note, there is a Proposed Risk in the Risk log dated as of 8/3/2009, It has been determined since the last set of meetings that this risk (DOT project schedule interfering with this one) will not happen because of differences in timing and because DOT will be developing and testing on instances separate from our Dev and Test environments.

As a follow up, Phase I for the implementation of the Optimization A recommendations has gone live on October 9, 2009. The Project Risk Assessment will be updated as part of the Planning Phase for Phase II.

2.0 PROJECT AUTHORITY AND ORGANIZATIONAL 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURESTRUCTURE

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.

2.1 STAKEHOLDERS2.1 STAKEHOLDERSList all of the major stakeholders in this project, and state why they have a stake. . Stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.

Phase I Stakeholder table

NAMENAME STAKE IN PROJECTSTAKE IN PROJECT ORGANIZATIONORGANIZATION TITLETITLE

ARTURO JARAMILLO Executive Sponsor and Member of IT Executive Steering Committee

General Services Department

Cabinet Secretary

ANTHONY ARMIJO Financial Control & Oversight and Member of Steering Committee

Department of Finance and Administration

Director of Financial Control & State Controller

JOHN PRIHODA Project Oversight and Member of Steering Committee

DFA, SHARE Project Project Manager

19


SUSAN STEINBERG Project Oversight DOT, SHARE Project Deputy Project Director

STEVEN YORE SHARE DoIT, SHARE System SHARE System Manager

MICHAEL VINYARD SPD Program Administrator and Member of Steering Committee

State Purchasing Division

Division Director & State Procurement Manager

ROSS BOOM Business Owner State Purchasing Division

Deputy Director

KATHY SANCHEZ Purchasing Subject Matter Expert


Executive Buyer Supervisor

ROSS BOOM Contracts Management State Purchasing Division

IT Related Group Supervisor

KEITH CAMPBELL Project Manager Oracle, Inc. Project Manager

EMILY KOYAMA Vendor Registration State Purchasing Division

Small Business Procurement Specialist

KAREN BALTZLEY Ensure project sufficiency. Liaison between multiple agencies and SPD business owners. Member of Steering Committee.

Office of the Secretary GSD - CIO

RYAN WOODARD Systems Technical Support GSD TSSB Generalist II

TOBI ANDRADE Functionally supports financial applications

DFA Support Unit Manager

GEORGE ROBINSON Technically supports application software

SHARE Technical Development Manager

20


DoIT ENTERPRISE OPERATIONS

Supports system hardware, Data Center, Oracle database, network and security infrastructure

DoIT

Vivian Montoya Financial Control Division responsible for Vendor File Maintenance and payment transactions

DFA FCD MANAGER

Note, for the Phase II implementation of the eProcurement functionality, we have identified the following Stakeholders.

Phase II – Anticipated Stakeholders to be validated by Planning Phase.


ARTURO JARAMILLO Executive Sponsor and Member of IT Executive Steering Committee

General Services Department

Cabinet Secretary

ANTHONY ARMIJO Financial Control & Oversight and Member of Steering Committee

Department of Finance and Administration

Director of Financial Control & State Controller

JOHN PRIHODA Project Oversight and Member of Steering Committee

DFA, SHARE Project Project Manager

SUSAN STEINBERG Project Oversight DOT, SHARE Project Deputy Project Director

STEVEN YORE SHARE DoIT, SHARE System SHARE System Manager

MICHAEL VINYARD SPD Program Administrator and Member of Steering Committee


Division Director & State Procurement Manager

21


ROSS BOOM Business Owner State Purchasing Division

Deputy Director

KATHY SANCHEZ Purchasing Subject Matter Expert


Executive Buyer Supervisor

ROSS BOOM Contracts Management State Purchasing Division

IT Related Group Supervisor

KEITH CAMPBELL Project Manager Oracle, Inc. Project Manager

TBD SME for Pilot Agency 1 TBD – Pilot Agency TBD Pilot Agency SME 1

TBD SME for Pilot Agency 2 TBD – Pilot Agency TBD Pilot Agency SME 2

KAREN BALTZLEY Ensure project sufficiency. Liaison between multiple agencies and SPD business owners. Member of Steering Committee.

Office of the Secretary GSD - CIO

RYAN WOODARD Systems Technical Support GSD TSSB Generalist II

TOBI ANDRADE Functionally supports financial applications

DFA Support Unit Manager

GEORGE ROBINSON Technically supports application software

SHARE Technical Development Manager

DoIT ENTERPRISE OPERATIONS

Supports system hardware, Data Center, Oracle database, network and security infrastructure

DoIT

22

2.2 PROJECT GOVERNANCE STRUCTURE2.2 PROJECT GOVERNANCE STRUCTURE2.2.1 D2.2.1 DESCRIBEESCRIBE THETHE ORGANIZATIONALORGANIZATIONAL STRUCTURESTRUCTURE – O – ORGRG C CHARTHART

2.2.2 D2.2.2 DESCRIBEESCRIBE THETHE ROLEROLE ANDAND MEMBERSMEMBERS OFOF THETHE PROJECTPROJECT STEERINGSTEERING COMMITTEECOMMITTEE

The table below represents the role and members of the Steering Committee for Phase 1, Optimization A.

Role NameExecutive Sponsor and Steering Committee Member

Arturo Jaramillo, GSD Cabinet Secretary

Designee to the Steering Committee for the Executive Sponsor

Pamelya Herndon, GSD Deputy Cabinet Secretary Designee

Steering Committee Member Michael Vinyard, SPD Division Director

23

Steering Committee Member and Project Oversight

John Prihoda, DFA/SHARE Project Manager

Steering Committee Member Anthony Armijo, DFA FCD DirectorSteering Committee Member Karen Baltzley, GSD CIOSteering Committee Member Margaret Trujillo, NMENV, Agency Representative

The table below represents the role and members of the Steering Committee for Phase II, will be validated by the planning phase.

Role NameExecutive Sponsor and Steering Committee Member

Arturo Jaramillo, GSD Cabinet Secretary

Designee to the Steering Committee for the Executive Sponsor

Pamelya Herndon, GSD Deputy Cabinet Secretary Designee

Steering Committee Member Michael Vinyard, SPD Division DirectorSteering Committee Member and Project Oversight

John Prihoda, DFA/SHARE Project Manager

Steering Committee Member Anthony Armijo, DFA FCD DirectorSteering Committee Member Karen Baltzley, GSD CIOSteering Committee Member TBD, Agency CIOSteering Committee Member TBD, Agency Representative

2.2.3 O2.2.3 ORGANIZATIONALRGANIZATIONAL B BOUNDARIESOUNDARIES, , INTERFACESINTERFACES ANDAND RESPONSIBILITIESRESPONSIBILITIES

Memorandum of Understanding is in place defining responsibilities of GSD and DFA in areas of fiscal and project management control. MOU executed: 10/2008.

See Attachment E: GSD and DFA Memorandum of Understanding for eProcurement Project.

A new Memorandum of Understanding will be developed (during the Planning Phase for Phase II) between GSD and DoIT.

2.3 EXECUTIVE REPORTING2.3 EXECUTIVE REPORTINGThe following approaches will be used:

oMeetings will be conducted with GSD Management and project teams on a regularly scheduled basis.

oWhiteboard sessions outlining project task and resource assignment schedules and agendas are conducted throughout the process and transferred to Microsoft project.

24

oProject team meetings are scheduled to coincide with the Vendor Implementation/Design teams for on-site implementation sessions. Frequency and length of meetings to be defined.

oProject status updates reports will be submitted on a monthly basis.

oGSD management will be kept informed on progress of the project periodically throughout the project life cycle.

oSpecial oral and written Project Management and IV&V reports will be given on project progress to the e-procurement Steering Committee.

3.0 SCOPE3.0 SCOPE

3.1 PROJECT OBJECTIVES3.1 PROJECT OBJECTIVES3.1.1 B3.1.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES


BUSINESS OBJECTIVE 1

Eliminate and or reduce current manual work overload


Significantly improve efficiency of procurement process, reduce errors


Support strategic sourcing through the process of capturing spend patterns and product usage across the state.


Allow access and use/improve efficiency of state agencies as well as local public body procurement processes


Reengineer SPD business processes to maximize utilization and benefits of an electronic procurement system


Provide automation to two of the current intensive manual business processes; Solicitation Release and Vendor Notification


Conduct an Oracle Health Assessment to define current state of software implementation and document final business requirements

25



(PHASE II EPRO)

Workflows and delivered on line inquiry (reporting) capabilities will provide further transparency and consistency in metric reporting


(PHASE II EPRO)

Workflows and supporting business processes delivered with eProcurement will enhance internal controls related to procurement activities

3.1.2 T3.1.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


TECHNICAL OBJECTIVE 1

Expand use of State-acquired PeopleSoft ERP software.

3.2 PROJECT EXCLUSIONS3.2 PROJECT EXCLUSIONSNone at this time.

3.3 CRITICAL SUCCESS FACTORS3.3 CRITICAL SUCCESS FACTORSIdentify the critical success factors for achieving success in this project. Metric are key to understanding the ability of the project to meet the end goals of the Executive Sponsor and the Business Owner, as well as the ability of the project team to stay within schedule and budget. See also section 6.7 Quality Objectives and Controls.


QUALITY METRICS 1

END USER TRAINING

End user Training will be mandatory and adequate for the purchasing functionality and/or modules implemented and completed before the end of the implementation phase.

26


QUALITY METRICS 2

ADEQUATE RESOURCES THROUGHOUT PROJECT

Resources from SPD, DFA, and Agencies will be available throughout the eProcurement Project Term as necessary to meet the e-procurement project schedule and scope.

QUALITY METRICS 3

SYSTEM ADMIN AND END USER SUPPORT BY KNOWLEGEABLE STAFF

Staff knowledgeable in purchasing business and procedures will be trained as End user Support technicians to provide effective support to purchasing community and SPD and Agency end users. Training will be completed and roles will be established during the planning and implementation phase.

QUALITY METRIC 4

COMPREHENSIVE TESTING

A comprehensive test plan will be developed to ensure effective functional, integration and regression testing of changes or added purchasing functionality

QUALITY METRIC 5 RESOURCE SUFFICIENCY

The project schedule, assigned tasks, resources and milestones are met.

QUALITY METRIC 6

BUDGET CONTROL

Project does not exceed budget.

QUAKITY METRIC 7

PURCHASING FUNCTIONALITY

SHARE Purchasing functionality and SPD operational functionality is optimized

QYALITY METRIC 8

PERFORMANCE MEASURES

Applicable SPD Legislative Performance Measures as stated in GSD FY09-10 Strategic Business and IT plan are met

QUALITY METRIC 9

SYSTEM

System is secure, operable and stable

QUALITY METRIC 10

DATA

Data integrity is maintained.

27

4.0 PROJECT DELIVERABLES AND METHODOLOGY4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE4.1 PROJECT MANAGEMENT LIFE CYCLEThe Table Below represents the phases for ePro Phase I and Phase II (ePro Implementation). At the end of the Planning Phase II (the implementation of ePro), Oracle will provide a crosswalk of these Key Deliverables in terms of their Implementation Methodology terms. Note, that we will be going for a Change Order for Planning Certification for the ePro Implementation.

Phase Summary of Phase Key Deliverables

Initiation Formal authorization to start project or project phase. Business needs and system requirements are documented and solution options are evaluated.

Project Charter DoIT Certification Initiation and Planning Phase Funding

secured PM contracted, Oracle contracted Kick Off Oracle Health Check Initial PMP built Project Schedule Initial Risk Assessment Project Schedule and Work Breakdown

Structure Requirements Definitions Vendor solutions and costs estimates

Planning Involve all identified stakeholders in planning and organizing a successful project. Identify, define and mature the project scope, project cost and project schedule. Identify and/or resolve dependencies, requirements, risks, assumptions, constraints, and strategies. Plan methods for monitoring and controlling the activities thru the project life.

Identification of functionality to be implemented in the eProcurement project within present budget.

Project Scope and WBS for implementing the identified solution

Project Schedule, including tasks, subtasks, milestones, with consideration for assumptions, risks, constraints, contingencies, external and internal critical dates

Defined Budget Management Plan with funding certification cycles

Test Plan

Plans for Risk Management,

28

Configuration Control, Business and Functional Process Re-engineering, End User Training, Internal and External Resource Management, Issue tracking and Change Management, Problem reporting and escalation.

Development of; Final Workflow Design Document

Project Management Plan Updated

Operations Framework and Management Policy and Procedures

Application Support Plan

Risk Assessment & Mitigation

Project Schedule Updated

Resource planning

Finalize IV&V contract and hire IV&V consultant

Set up test region, if appropriate, and indicated by Health Check Recommendations.

Draft TARC documents for Review

Confirm system processing capacity requirements

Implementation/Execution

Complete the work defined in the Project Management Plan. Develop Optimization A items

Identify and specify test regions

Request Set-up of test region, as appropriate.

Unit Test and/or validate configuration modifications in simulated production test environment and with test data samples that simulate production data

Re-engineer Business processes related to Optimizations

29

Update UPK’s for new configurations or re-engineered Business processes

Develop and execute UAT

Develop and execute Regression testing plan

Develop and execute training plan

Develop and execute Change Management Plan

Migrate Optimizations from test environment to production Conduct Operational Readiness tests and validations

Initiate use of optimizations and re-engineered business processes in production environment

Confirm Move to Production complete

Monitor and Control/Stabilization Period

Perform processes to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project.

30 –day Monitor and document Purchasing business outcomes and user experience resulting from the optimized functionality and re-engineered business processes.

Control Report problems and apply identified corrective action

Close Formally terminate all activities of a project or a project phase and hand off the completed product to others.

DoIT Closure Report, Project Closure Archive, IV &V Close out report, Post Mortem)

4.1.1 P4.1.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

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.

30

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE DDESCRIPTIONESCRIPTION AACCEPTANCECCEPTANCE

eProc-Proj

DEL-1

Project Charter

The Project Charter for Certification sets the overall scope for the project, the governance structure, and when signed is considered permission to proceed with the project. The Project Charter for Certification is used to provide the Project Certification Committee with adequate knowledge of the project and its planning to certify the initiation phase of the project

Deliverable Acceptance Criteria

According to DoIT requirements and State of NM policies and procedures.

Standards for Content and Format

According to DoIT requirements, standards and templates.

Quality Review

Monthly by GSD/SPD Business owner, eProc Project Mgr and DFA Oversight

Presentation as required and certification by DoIT and PCC.

eProc-Proj

DEL-2

Certification Form

The Request for Certification and Release of Funds form is submitted when a project goes for any of the certification phases. It deals with the financial aspects of the project, as well as other topics that indicate the level of planning that has gone into the project. Many of the questions have been incorporated into the preparation of the project charter


According to DoIT requirements and State of NM policies and procedures.


According to DoIT requirements, standards and templates.

31

Quality Review



eProc Proj DEL -3

Oracle Health Check Assessment Report

Contractor shall:-provide a documented assessment of the State of New Mexico (SoNM)current use of the PeopleSoft procurement applications,-provide written recommendations of how the SoNM can implement thepurchased PeopleSoft applications to achieve GSD/SPD written goals andrequirements for eProcurement and strategic sourcing,-provide written recommendations as to how SoNM can best implementother PeopleSoft supply chain applications in phased pieces to further

achieve the SoNM eProcurement goals and requirements.

Deliverable Acceptance Criteria In accord with Section 13-1-158 NMSA 1978; the eProcurement Project Manager, Project Team, Executive level Sponsors and Steering Committee will assess the quality and determine, at a minimum, that the Deliverable:1.) Complies with the Deliverable requirements as defined in Exhibit A, of the Contract Agreement.2.) Complies with the terms and conditions of the Contract Agreement;3.) Meets the performance measures for the Deliverable(s) and the Contract Agreement;

4.) Complies with all the requirements of the contract agreement.

32


As set forth in the Contract Agreement or required by the Project Team and according to DoIT requirements, standards and templates.

Quality Review


Monthly Presentation and review by Executive Steering Committee.

33

eProc Proj DEL -4

Budgetary Estimates for Oracle Recommendations

The Contractor shall:-provide a phased approach methodology with written documentation,including cost estimates and implementation strategies for what it wouldtake to implement the eProcurement and Strategic Sourcing modules tomeet the business processes covered by the workflows identified in item 1.1above,-provide a written estimate to complete the implementation of the proposedsuite of Supplier Relationship Management (SRM) modules in the SoNM’s future budget years.

Deliverable Acceptance Criteria In accord with Section 13-1-158 NMSA 1978; the eProcurement Project Manager, Project Team, Executive level Sponsors and Steering Committee will assess the quality and determine, at a minimum, that the Deliverable:1.) Complies with the Deliverable requirements as defined in Exhibit A, of the Contract Agreement.2.) Complies with the terms and conditions of the Contract Agreement;3.) Meets the performance measures for the Deliverable(s) and the Contract Agreement;

4.) Complies with all the requirements of the contract agreement.

34


As set forth in the Contract Agreement or required by the Project Team and according to DoIT requirements, standards and templates.

Quality Review


Monthly Presentation and review by Executive Steering Committee.

eProc-Proj

DEL-5

Project Management Plan

“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 plan.”

Deliverable Acceptance Criteria According to DoIT requirements, standards and templates.

Standards for Content and Format - According to DoIT requirements, standards and templates.

Quality Review - Monthly by GSD/SPD Business owner, eProc Project Mgr and DFA Oversight


35

eProc-Proj

DEL-6

IV&V Contract & Reports

“Independent verification and validation (IV&V)” means the process of evaluating a project to determine compliance with specified requirements and the process of determining whether the products of a given development phase fulfill the requirements established during the previous stage, both of which are performed by an organization independent of the lead agency. Independent verification and validation assessment reporting. The Department requires all projects subject to oversight to engage an independent verification and validation contractor unless waived by the Department.


TBD. Will be according to DoIT requirements for IV&V and as set forth in the IV&V Contract Scope, terms and conditions.

Standards for Content and Format - According to DoIT requirements, standards and templates.

Quality Review - Monthly by GSD/SPD Business owner, eProc Project Mgr and DFA Oversight


eProc-Proj

DEL-7

IT Service Contracts

The Department of Information Technology and the State Purchasing Division of General Services have established a template for all IT related contracts.

Deliverable Acceptance Criteria TBD in Planning Phase and with consideration for Health Check Recommendations.

Standards for Content and Format – TBD in Planning Phase

Quality Review – TBD in Planning Phase

36

eProc-Proj

DEL-8

Risk Assessment and management

The DoIT Initial PROJECT RISK ASSESSMENT template which is meant to fulfill the following requirement: “Prepare a written risk assessment report at the inception of a project and at end of each product development lifecycle phase or more frequently for large high-risk projects. Each risk assessment shall be included as a project activity in project schedule.” Project Oversight Process memorandum

Deliverable Acceptance Criteria - As set forth in the Contract Agreement or required by the Project Team and according to DoIT requirements, standards and templates.

Standards for Content and Format - - According to DoIT requirements, standards and templates.

Quality Review Weekly monitoring and Risk updates by Project Mgr and Project Team... Monthly Risk/Issue updates provided with Project status reports to GSD/SPD Business owner and Project Team, Executive Steering Committee.

Proj Mgr follows proper escalation steps with changes to existing or new risks.

Risk Management Plan and Risk Log included as required with certification documents for DoIT and PCC presentations and monthly reporting.

37

eProc-Proj

DEL-9

Project Schedule

A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. The de-facto standard is Microsoft Project

Deliverable Acceptance Criteria – Proj Mgr and Proj Team monitor task and schedule progress, weekly.

Monthly: updated Project schedule included with Project Status Report to Executive Sponsors and Steering Committee.

Updated schedule provided as required with DoIT and PCC certification documents.

Standards for Content and Format: MS Project format. Updates provided as HTML views for Team members and project stakeholders.

PM will use GSD preferred format and views for displaying progress , Report and views on progress, resource utilization, task tracking

38

Quality Review –

Weekly review by Project Team, SPD Business Owner, DFA Oversight

Monthly Status Reports reviewed by GSD/SPD Business owner, eProc Project Mgr and DFA Project Sponsors


eProc-Proj

DEL-10

Monthly Project Status Reports to DoIT

Project status reports. For all projects that require Department oversight, the lead agency project manager shall submit an agency approved project status report on a monthly basis to the Department.

Deliverable Acceptance Criteria – PM provides GSD CIO with updated Monthly Report in DoIT format by the 9th of each month

Monthly Status Report submitted to DoIT by GSD CIO by the 10th of each month

Standards for Content and Format – DoIT Monthly Report template

Quality Review – monthly by GSD CIO

eProc-Proj

DEL-11

Project Closeout Report

This is the Template used to request that the project be officially closed. Note that project closure is the last phase of the certification process

Deliverable Acceptance Criteria – According to DoIT requirements and templates and State of NM policies and procedures.

39

Standards for Content and Format DoIT and State of NM

Quality Review TBD but will involve participation by PM, Project Team, SPD Business Owner, DFA Oversight, GSD CIO, and Executive Steering Committee.

4.1.2 D4.1.2 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

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.

Phase I Deliverables.


DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W(WHOHO CANCAN APPROVEAPPROVE))

DDATEATE A APPROVEDPPROVED

eProc-Proj DEL-001

Project Charter and Initiation Phase Request

Steering Committee

Sept 11, 2008

eProc-Proj DEL-002

Initiation Phase Certification Form DoIT PCC October 8, 2008

eProc-Proj DEL-003

Project Management Plan (PMP) Project Team,

DFA, with consultation from GSD, as set forth in the eProcurement MOU,

Executive Steering Committee

Initial PMP 2/13/09

PMP will be updated, ongoing and as required for remainder of project term.

40




eProc-Proj DEL-004

IV&V Contract (DFA to execute)

IV&V Reports

Project Team,



8-4-09

eProc-Proj DEL-005

IT Service Contracts (DFA to execute)

Project Team,



Not Applicable

SHARE already has a SLA agreement with DoIT

eProc-Proj

DEL-006

Risk Assessment and management Project Team,



Ongoing

Last provided

8-7-09

41




eProc-Proj DEL-007

Project Schedule Project Team,



1-29-09

Last Revision

10-09-2009

eProc-Proj DEL-008


GSD CIO

SPD Business Owner

Executive Project Sponsors

Ongoing

Last provided

10-09-09

eProc-Proj DEL-009

Project Closeout Report Project Team,



Anticipated November 2009

42

Phase II Deliverables.




eProc-Proj DEL-010

Change Order for Optimization B - Initiation and Planning Phase Certification Form for Phase II – ePro

Steering Committee

Anticipated October 28, 2009

eProc-Proj DEL-011

Updated Project Management Plan (PMP) for Opt B

Project Team,

DoIT, with consultation from GSD, as set forth in the eProcurement MOU,


eProc-Proj DEL-012

IV&V Contract (DFA to execute)

IV&V Reports

Project Team,



eProc-Proj DEL-013

IT Service Contracts (DFA to execute)

Project Team,

DFA, with consultation from GSD, as set forth in the eProcurement

43




MOU,


eProc-Proj

DEL-014

Updated Risk Assessment and management

Project Team,



eProc-Proj DEL-015

Project Schedule for new Implementation

Project Team,



eProc-Proj DEL-016


GSD CIO

SPD Business Owner

Executive Project Sponsors

44




eProc-Proj DEL-017

TBD Deliverables – for the Phase II that will be developed during the Planning Phase.

Project Team,



eProc-Proj DEL-018

Project Closeout Report Project Team,



4.1.3 D4.1.3 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Describe the process that this project will use for the formal acceptance of all deliverables.

The Business Owner, SPD and the eProcurement Team will review completed deliverables to certify that specifications and requirements and/or contract obligations have been satisfied. The eProcurement Team will vote to accept or reject the deliverable and provide the Team’s majority decision, in writing, to DFA Oversight for approval of payment of vendor invoices. . T

45

If the deliverable is rejected, SPD/Business Owner, will inform DFA Oversight, Executive Sponsors and Steering Committee, in writing, of the reason for the rejection, and actions required by the vendor before the deliverable is presented for acceptance again.

4.2 PRODUCT LIFE CYCLE4.2 PRODUCT LIFE CYCLE “During the project management lifecycle, agencies shall select and implement a phase product development lifecycle methodology approved by the Department.” PROJECT OVERSIGHT PROCESS Memorandum

Phase Summary of Phase Key Deliverables

Initiation Develop project initiation and justification documents

Define Business Requirements through Surveying Business Owners and Subject Matter Experts, Complete Project Scope, Finalize PM contract & hire, Finalize Oracle Contract for Health Assessment, Conduct Health Assessment

Planning Produce the requirements work products, including business and technical requirements documents and the initial overall and eProcurement project schedules

Development of; Final Workflow Design Document, Project Management Plan, Operations Framework and Management Policy and Procedures, Application Support Plan, Risk Assessment & Mitigation, Project Schedule, Scope definition and cost estimates for workflow design and implementation, resource planning. Draft IV & V contract and plan, finalize IV&V contract and hire IV&V, consultant, set up test region, estimate bandwidth utilization requirements, confirm system processing capacity

46

requirements

Implementation Maintain planning focus and revisions to the project schedules; regular project evaluation and status; produce work products and deliverables according to the schedule; maintain requirements traceability

Identified workflow design incorporating functionality from Strategic Sourcing and eProcurement modules software configured/ installed in test region; data conversion/ migration and or new data input; test; implement into production; team development and attend SME functional training; conduct vendor training; user acceptance; PM/IV &V periodic reports; test DR if available; QA, transition to operations)

Closeout Complete project close out activities according to the plan; initiate post-deployment activities, including transition of pending action items for post-deployment handling


Note, a crosswalk to these Phases will be provided as part of our Phase II Planning Stage activities.

4.2.1 T4.2.1 TECHNICALECHNICAL S STRATEGYTRATEGY

Discuss the key technical strategies for achieving success in this project.

This project will build upon the existing infrastructure and e-procurement knowledge base of the State of New Mexico SHARE system by fully implementing State owned PeopleSoft procurement application modules and Strategic Sourcing, where effective, that will enhance and automate the State Purchasing Division (SPD). This will enable SPD to implement and follow consistent, controlled, accountable, efficient processes and provide Strategic Sourcing capabilities to all state agencies and other public entities utilizing eSourcing methodologies and practices.

47

SPD plan is to leverage the existing work done to align the business processes from the SHARE implementation and the internal SPD business, functional and project management knowledge and skills in collaboration with external support to complete this implementation. The outcomes will include e-procurement savings through the use of implemented State owned PeopleSoft procurement application modules, Strategic Sourcing and eProcurement.

.

4.2.2 P4.2.2 PROJECTROJECT ANDAND P PRODUCTRODUCT D DEVELOPMENTEVELOPMENT D DELIVERABLESELIVERABLES

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.


DDELIVERABLEELIVERABLE DDESCRIPTIONESCRIPTION AACCEPTANCECCEPTANCE

eProc-Product

DEL-1

Requirements Documents

A Requirements Document has been developed that defines the SPD Business Processing priorities. A baseline for SHARE processing capabilities as compared to business requirements in the current environment was defined and documented. (Refer Appendix B)

Meetings were held with the SME’s for the SPD units to define business processing requirements

Deliverable Acceptance Criteria TBD in Development and Test Preparation stageStandards for Content and Format TBD in Development and Test Preparation stage

Quality Review -

TBD in Development and Test Preparation stage

eProc-Product

DEL-2

Design Documents

The SPD workflow against current SHARE workflow was mapped and documented. Gaps in current system were documented. Gaps in SPD business processing that the “proposed” implementation of the e-Procurement and Strategic Sourcing modules would not address at this

Deliverable Acceptance Criteria - TBD in Development and Test Preparation stageStandards for Content and Format - TBD in Development and Test Preparation stage

48

time were also identified. (Refer Appendix C)

Quality Review - TBD in Development and Test Preparation stage

eProc-Product

DEL-3

Systems Specifications

Will implement modules on existing SHARE platform. Optimizations, changes and new functionalities will be based on Health Check Recommendations and strategic approach for implementing improvements.

May utilize email notification and Crystal Reports tool and GUI interface, if recommended by Oracle and if identified as part of the strategic approach for improvements to be implemented.

Deliverable Acceptance Criteria - TBD in Development and Test Preparation stage

Standards for Content and Format - TBD in Development and Test Preparation stageQuality Review - TBD in Development and Test Preparation stage

eProc-Product

DEL-4

Systems Architecture

The system will be certified on PeopleSoft operating platforms. Architecture will be scalable to allow for growth, provide interoperability with other systems, have a secure web front end, be security rules based and provide multiple security layers for user authentication.


Standards for Content and Format - TBD in Development and Test Preparation stageQuality Review - TBD in Planning Phase

eProc-Product

DEL-5

System and Acceptance Testing

The SPD Functional Program Users, FCD Vendor Maintenance Users, and Agency Purchasing Users will test system functionality, performance, reporting accuracy and response times.


Standards for Content and Format - TBD in Development and Test Preparation stage

49

SHARE IT Technical Support Staff will test system operational performance.

Quality Review - TBD in Development and Test Preparation stage

eProc-Product

DEL-6

Operations requirements

The implementation vendor will be required to deliver design and maintenance documents for Authentication, Software, Reporting, and Database feeds.

Deliverable Acceptance Criteria - TBD in Development and Test Preparation stageStandards for Content and Format -

TBD in Development and Test Preparation stageQuality Review - TBD in Development and Test Preparation stage

4.2.3 D4.2.3 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

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.

Deliverable Number Deliverable

Approvers

(Who can approve)Date

Approved

eProc-Product DEL-1

Health check Assessment eProcurement Team, SHARE IT Support, SPD Business Owner, Executive Sponsors

2-10-09

eProc-Product DEL-2

Budgetary Estimates and Implementation Strategies

eProcurement Team, SPD Business Owner, Executive Sponsors

4-27-09

eProc-Product

DEL-3

Planning Phase Documentation


2-27-09

50


Approvers


Approved

eProc-Product

DEL-4

Project Plan eProcurement Team, SHARE IT Support, SPD Business Owner, Executive Sponsors

1-26-09 Last

Revision 10-13-09

eProc-Product

DEL-5

Project Schedule eProcurement Team, SHARE IT Support, SPD Business Owner, Executive Sponsors

1-26-09 Last

Revision 10-09-09

eProc-Product

DEL-6

Core Purchasing Development Activities


7-31-09

eProc-Product

DEL-7

Vendor Maintenance Development Activities


7-13-09

eProc-Product

DEL-8

Purchasing Contract Development Activities


7-16-09

eProc-Product

DEL-9

Core Purchasing Prototype Activities

eProcurement Team, SHARE IT Support, SPD Business Owner, FCD SME’s, Agency SME’s, Executive Sponsors

6-5-09

eProc-Product

DEL-10

Vendor Maintenance Prototype Activities


6-22-09

eProc-Product

DEL-11

Purchasing Contract Prototype Activities

eProcurement Team, SHARE IT Support, SPD Business Owner, FCD SME’s, Agency SME’s,

7-2-09

51


Approvers


Approved

Executive Sponsors

eProc-Product

DEL-12

Core Purchasing UPK Activities

eProcurement Team, SPD Business Owner, FCD SME’s, Agency SME’s, Executive Sponsors

7-24-09

eProc-Product

DEL-13

Vendor Maintenance UPK Activities


6-1-09

eProc-Product

DEL-14

Purchasing Contract UPK Activities


7-2-09

eProc-Product

DEL-15

Core Purchasing UAT and Regression Testing Activities


8-26-2009

eProc-Product

DEL-16

Vendor Maintenance UAT and Regression Testing Activities


8-26-2009

eProc-Product

DEL-17

Purchasing Contracts UAT and Regression Testing Activities


8-26-2009

eProc-Product

DEL-18

Rollout, Stabilization, and Close Support requirements

eProcurement Team, SHARE IT Support, SPD Business Owner, FCD

52


Approvers


Approved

SME’s, Agency SME’s, Executive Sponsors

The Table below represents Deliverables for the Phase II (Implement ePro) project


Approvers


Approved

eProc-Product DEL-10

Change Order for Phase II

DoIT PCC

eProc-Product

DEL-11

Updated Project Management Plan (PMP)


eProc-Product

DEL-12

IV&V Contract eProcurement Team, SHARE IT Support, SPD Business Owner, Executive Sponsors

eProc-Product

DEL-13

IT Service Contracts eProcurement Team, SHARE IT Support, SPD Business Owner, Executive Sponsors

eProc-Product

DEL-14

Updated Risk Assessment and Management


eProc-Product

DEL-15

Project Schedule for New Implementation


eProc-Product

DEL-16

Monthly Status Reports eProcurement Team, SPD Business Owner, Executive Sponsors

53


Approvers


Approved

eProc-Product

DEL-17

TBD – Deliverables for the Implementation


eProc-Product

DEL-18

Close Activities eProcurement Team, SHARE IT Support, SPD Business Owner, FCD SME’s, Agency SME’s, Executive Sponsors

NNOTEOTE, , THETHE DELIVERBALESDELIVERBALES ININ THETHE TABLESTABLES ABOVEABOVE WILLWILL BEBE UPDATEDUPDATED ATAT THETHE COMPLETIONCOMPLETION OFOF THETHE P PLANNINGLANNING P PHASEHASE ACTIVITIESACTIVITIES..

4.2.4 D4.2.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE

Describe the process that this project will use for the formal acceptance of all deliverables.

The Business Owner, SPD and the eProcurement Team will review completed deliverables to certify that specifications and requirements and/or contract obligations have been satisfied. The eProcurement Team will vote to accept or reject the deliverable and provide the Team’s majority decision, in writing, to DFA Oversight for approval of payment of vendor invoices. . T

If the deliverable is rejected, SPD/Business Owner, will inform DFA Oversight, Executive Sponsors and Steering Committee, in writing, of the reason for the rejection, and actions required by the vendor before the deliverable is presented for acceptance again.

54

5.0 PROJECT WORK5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)5.1 WORK BREAKDOWN STRUCTURE (WBS)A WBS is a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Describe the work activities that comprise the work breakdown structure (WBS) or the work packages within the WBS. Identify the WBS element or other work package identifier and provide a general description of the tasks or activities, the definition or objectives, and the milestones and deliverables of each work package.

Use the chart below for highest level presentation, and provide a more detailed WBS as an attachment to this project plan.

See Attachment A: Project Schedule and Work Breakdown Structure

55

Identifier Work Package Description Definition/Objective Milestone/Deliverable

2 Initiation Phase Formal authorization to start project or project phase. Business needs and system requirements are documented and solution options are evaluated.

Project Charter DoIT Certification Initiation and Planning Phase

Funding secured PM contracted, Oracle contracted Kick Off Oracle Health Check Initial PMP built Project Schedule Initial Risk Assessment Project Schedule and Work

Breakdown Structure Requirements Definitions Vendor solutions and costs

estimates

3 Initiation Phase Project Administration

Project Executives from DFA, and GSD/SPD administer and develop contracts, obtain funding, according to requirements of DoIT, DFA, and State of New Mexico procurement and contract policies and procedures.

9 Initiation phase Project Control

Compare actual performance with planned performance.

Monitoring progress

analyze variances

assess trends affecting process improvements, when necessary

evaluating possible alternatives and recommending appropriate corrective actions.

56


43Certification Process Planning and Implementation Phases

develop, compile, and complete with assistance from the Project Manager and Project Team the

DoIT Planning Phase Project Certification documentation,

-participate in presentation of certification materials to DoIT Project

Certification Committee members.

Planning Phase Certification Documents and presentation before the PCC

Implementation Phase Certification Document and presentation before the PCC

Monthly Status Reports and Status Update presentations as required and requested by DoIT and PCC.

Close Phase Certification Documentation

53Project Management Application of standard

practices, knowledge, skills, tools, techniques to project activities to achieve the project objectives

Del 1: Initial PMP

Del 2: Oversee, coordinate, facilitate Health Check Activities

Del 3: Update PMP

Del 4: Manage Project Executions of eProcurement Project

57


109Oracle Health Check The Oracle Health

Check™ and resulting proposed system enhancements will provide

definitive direction to State Purchasing on methods to automate division processing that will

allow SPD to manage vendor notification, registration and e-pay of vendor registration fees,

Issue solicitations, facilitate e-receipt of bids and proposals and perform e-posting.

Additionally, the project will document the current state of installation of the SHARE

procurement modules that were purchased by the State as defined during the Oracle Health

Assessment that will be conducted.

Del 1: Health check Assessment

Del 2: Budgetary Estimates

58


143 Planning Phase Involve all identified stakeholders in planning and organizing a successful project. Identify, define and mature the project scope, project cost and project schedule. Identify and/or resolve dependencies, requirements, risks, assumptions, constraints, and strategies. Plan methods for monitoring and controlling the activities thru the project life.

Identification of functionality to be implemented in the Implementation Phase of the eProcurement project

Project Scope and WBS for implementing the identified solution

Project Schedule, including tasks, subtasks, milestones, with consideration for assumptions, risks, constraints, contingencies, external and internal critical dates

Defined Budget Management Plan with funding certification cycles

Test Plan

Plans for Risk Management, Configuration Control, Business and Functional Process Re-engineering, End User Training, Internal and External Resource Management, Issue tracking and Change Management, Problem reporting and escalation.

Development of; Final Workflow Design Document

Project Management Plan Updated

Operations Framework and Management Policy and Procedures

Application Support Plan

Risk Assessment &

59


160 Implementation Phase Complete the work defined in the Project Management Plan.

Develop Optimization A items

Identify and specify test regions

Request Set-up of test region, as appropriate.

Unit Test and/or validate configuration modifications in simulated production test environment and with test data samples that simulate production data

Re-engineer Business processes related to Optimizations

Update UPK’s for new configurations or re-engineered Business processes

Develop and execute UAT

Develop and execute Regression testing plan

Develop and execute training plan

Develop and execute Change Management Plan

Migrate Optimizations from test environment to production Conduct Operational Readiness tests and validations

Initiate use of optimizations and re-engineered business processes in production environment

Confirm Move to Production

60


160 Implementation Phase Monitor and Control/Stabilization period


30 –day Monitor and document Purchasing business outcomes and user experience resulting from the optimized functionality and re-engineered business processes.Control Report problems and apply identified corrective action

416 Close Phase Formally terminate all activities of a project or a project phase and hand off the completed product to others.


230 IV&V Review Reports Per requirements of DoIT and eProc Project.

Per DoIT requirements, PMP and IV&V contract scope and terms and conditions

Phase II schedule

61


Initiation Phase Formal authorization to start project or project phase. Business needs and system requirements are documented and solution options are evaluated.

TBD Planning Phase

Initiation Phase Project Administration

Project Executives from DFA, and GSD/SPD administer and develop contracts, obtain funding, according to requirements of DoIT, DFA, and State of New Mexico procurement and contract policies and procedures.

TBD Planning Phase

Initiation phase Project Control

Compare actual performance with planned performance.

TBD Planning Phase

Certification Process Planning and Implementation Phases

develop, compile, and complete with assistance from the Project Manager and Project Team the

DoIT Planning Phase Project Certification documentation,

-participate in presentation of certification materials to DoIT Project

Certification Committee members.

TBD Planning Phase

Project Management Application of standard practices, knowledge, skills, tools, techniques to project activities to achieve the project objectives

TBD Planning Phase

62


Oracle Health Check The Oracle Health Check™ and resulting proposed system enhancements will provide

definitive direction to State Purchasing on methods to automate division processing that will

allow SPD to manage vendor notification, registration and e-pay of vendor registration fees,

Issue solicitations, facilitate e-receipt of bids and proposals and perform e-posting.

Additionally, the project will document the current state of installation of the SHARE

procurement modules that were purchased by the State as defined during the Oracle Health

Assessment that will be conducted.

TBD Planning Phase

63


Planning Phase Involve all identified stakeholders in planning and organizing a successful project. Identify, define and mature the project scope, project cost and project schedule. Identify and/or resolve dependencies, requirements, risks, assumptions, constraints, and strategies. Plan methods for monitoring and controlling the activities thru the project life.

TBD Planning Phase

Implementation Phase Complete the work defined in the Project Management Plan.

TBD Planning Phase

Implementation Phase Monitor and Control/Stabilization period


TBD Planning Phase

Close Phase Formally terminate all activities of a project or a project phase and hand off the completed product to others.

TBD Planning Phase

IV&V Review Reports Per requirements of DoIT and eProc Project. TBD Planning Phase

5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE

64

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

See Attachment A: eProcurement Project Schedule, Milestones and Tasks

Note, the schedules below will be detailed in this section at the end of the Phase II Project Planning Phase. Below is a proposed schedule for Phase II.

October 2009 – begin Intiation Phase (no funding required)

November 2009 – February 2010 – Planning Phase Activities

February– June 2010 – Implementation Activities

June – July 2010 – Lessons Learned, Project Closeout with updated Cookbook

August 2010 – TBD – rollout to additional agencies utilizing Cookbook.

65

12/15/2008 2/25/2009

eProcurement Project Timeline2/26/09-4/22/2009

Planning Phase 4/23/2009-9/30/2009

-Implementation PhaseCloseout

12/15/2008-2/25/2009Initiation Phase

4/22/2009

10/1/2009-10/31/2009

9/30/2009 10/31/2009

5.3 PROJECT BUDGET5.3 PROJECT BUDGET

Costs estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).

Phase / Activity Associated Deliverables Estimated Budget

Phase 1: Project Preparation, Initiation

Define Business Requirements through Surveying Business Owners and Subject Matter Experts, Complete Project Scope, Finalize PM contract & hire, draft IV & V contract and plan, Finalize Oracle Contract for Health Assessment, Conduct Health Assessment, draft IV&V contract (PM- $50.0, Oracle Health Assessment - $42.0)

$92,000

Phase 2: Planning Development of; Final Workflow Design Document, Project Management Plan, Operations Framework and Management Policy and Procedures, Application Support Plan, Risk Assessment & Mitigation, Project Schedule, Scope definition and cost estimates for workflow design and implementation, resource planning. Finalize IV&V contract and hire IV&V consultant, set up test region, estimate bandwidth utilization requirements, confirm system processing capacity requirements (PM - $115.0, Oracle Professional Services $30.0 )

$145,000

Phase 3: Implementation

Identified workflow design incorporating functionality from Strategic Sourcing and eProcurement modules software configured/ installed in test region; data conversion/ migration and or new data input; test; implement into production; team development and attend SME functional training; conduct vendor training; user acceptance; PM/IV &V periodic reports; test DR if available; QA, transition to operations ( Oracle Professional Services -$247.0, IV&V - $8.0, Contingency $8.0, PM committed in Planning Phase).

$263,000

67

Phase / Activity Associated Deliverables Estimated Budget

Phase 4Project Closing


TOTALS $500,000

The table below represents estimated Budget Amounts for the Phase II

ITEM ESTIMATE

Project Management and Professional Services

Oracle – note amounts to the right are estimated to be determined by planning and are inclusive of Planning Phase Activities.

$300,000 – 350,000

IV&V $8,000

Hardware $ 0

Software $ 0


Provision / leftover if needed for additional rollouts

This is really leftover from the $435,000 amount

113,950 – 63,950

Contingency 3% of $435,000 $13,050


$435,000

5.4 PROJECT TEAM5.4 PROJECT TEAM5.4.1 P5.4.1 PROJECTROJECT T TEAMEAM O ORGANIZATIONALRGANIZATIONAL S STRUCTURETRUCTURE

Insert a graphical Organization Chart here. The Organizational Structure (OS) is a hierarchical configuration defining levels of program management and may identify all project personnel.

68

The OS should be simple and straightforward. Include role names and people’s names. Consider identifying the core project team by shading their respective boxes on the chart. On complex projects, consider using a second OS to identify core project team. The OS can also be used for management reporting.

5.4.2 P5.4.2 PROJECTROJECT T TEAMEAM R ROLESOLES ANDAND R RESPONSIBILITIESESPONSIBILITIES

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.

PPROJECTROJECT T TEAMEAM M MEMBEREMBER RROLEOLE RRESPONSIBILITYESPONSIBILITY

69

Arturo Jaramillo, Cabinet Secretary

Executive Project Sponsor

The point person for the project within the highest level of the General Services Department.

Responsibilities include: Champion the project. Consider potential changes facing the

organization and assess the organizational impact

Decide which changes will be instituted, communicate priorities and provide resources to ensure success

Responsible for creating an environment that enables changes to be made on time and within budget.

Participate in planning sessions Member of Steering Committee Ultimate project responsibility

Arturo Jaramillo, Cab Sec

Marilyn Hill, Dep. Cab Sec

Pamelya Herndon, Dep. Cab. Sec.

Michael Vinyard, Div Dir

John Prihoda, SHARE Project Director

Anthony Armijo, DFA FCD Director

Karen Baltzley, GSD CIO

Margaret Trujillo, NMENV

Steering Committee Members

Is chartered to provide governance over the direction and support of the project.

Responsibilities include: Attend and participate in meetings Review and provide comment on presented

documentation Balance larger picture versus details of the

project Review project funding and expenditures Champion the project Contributes to lessons learned

Ross Boom, SPD Business The person within each of the participating

70

Owner Divisions who is responsible for all operations and management of any and all activities occurring within the division.

Responsibilities Include: Maintain overall project direction and

implementation Ensure staff availability Approve expenditure of funds Issue Resolution

Empower Project Manager

Keith Campbell, PM, Oracle Project Manager

The persons within each of the participating divisions who must make all decisions related to the operation of the system, staffing assignments,

Responsibilities Include: Ultimate project success. Diagnose potential problems Participate as “change” agents Develop realistic plans to deal with critical

issues and execute changes effectively Decision authority regarding system

module set-up Reviews work of Consultant Project Team Support Member

Assignments Determine System Administration roles Problem Solving Project Planning Project Budgeting Project Schedule Contract Management Training Plans Communicate with Project Team Support

Members, Business Owners and Steering Committee.

Contributes to lessons learned.

71

SPD Central Purchasing

Kathy Sanchez/SPD

Gerri Becker/SPD

Emily Koyama/SPD

Rick Muniz/SPD

Mike Riggs/SPD

Laura Markley/SPD

India Garcia/SPD

Gary Chavez/SPD

FCD Subject Matter Experts

Vivian Montoya, FCD Mgr

Dorothy Padilla

Gianna Rodriguez

Agency Purchasing

Michelle Randall/CYFD

Vivian Montoya/DFA

Paul Kippert/DFA

Joan Trujillo/DFA

Dorothy Padilla/DFA

Gianna Rodriguez/DFA

Denise Pierce/DOH

Bernice Gonzales/DOH

Marcos Lopez/DOT

Carmella Romero/DOT

Henrietta Leos/DOT

Paul Sealy/DPS

Lisa VigildePino/DPS

Mark Rowley/DPS –Motor Trans

Andrea Romero/DPS-Motor

Project Team Support Members

Staff assigned to the project on an as needed basis.

Responsibilities Include: Define Buyer Requirements Define Vendor Requirements Define Contracts, RFP, ITB, Sole Source,

GSA Requirements Define Business Requirements Module set-up input Functional Testing Scheduling of meetings and space Completion of assigned tasks Budget Tracking Purchasing and Processing Data Gathering Data Input System Administration Provide Resources as needed.

72

Trans

Danni Sutana/HSD

Albert Montano/NMCD

Phillip Senior/NMCD

Rafael Torres/NMCD

Margaret Trujillo/NMED

DoIT DFA Technical Support

Tobi Andrade/DFA

George Robinson/DFA

Bill York, DoIT

Henry Brown, DoIT

Neil Perrone, DoIT

Bryan Wilson, DoIT

Fernando Mondala, DoIT

Ryan Woodard, GSD

Sujatha Seethapathi, GSD

Technical Support

SHARE/DoIT Staff assigned to assist in defining infrastructure requirements and providing on-going support

Duties Include; System/infrastructure Specifications Integration to other systems Requirements Data back-up and storage requirements Security Rules Data migration System installation Provide network connectivity and remote

access Report Tool database Provide test/development environment Conduct system/network testing System Maintenance/Support Disaster Recovery Anti-Virus Protection Provide transition to operations guidelines

and documentation

System recovery requirements

Desktop

Local Area Network

The table above represented the team for Project Phase I (Optimization A). At the conclusion of Planning Phase activities for Phase II we will present a new table below for that project.

73

5.5 STAFF PLANNING5.5 STAFF PLANNING AND RESOURCE ACQUISITIONAND RESOURCE ACQUISITIONComplete the chart below identifying the project team members and details concerning their project commitment. Project staff should include State, Contract, Customer (Business Owner), or Vendor team members

WBS Task DoIT DFASHARE

SPD Business Owner

eProc Project Team

ESC Project Mgr

Vendor

Oracle Team Vendor

SPD Functio

nal SME’s

and Users

FCD Vendor

File Maint. SME’s

and Users

Agency Functional SME’s and

Users

IV&V

Vendor

Project ManagementPlanning

Business Requirements

X X X

Project Management

Plan including

Scope & WBS

Project Schedule

X X X

eProc modules Health Check

X X X X X

Risk Management

X X X X

Communication X X X X X X X X


SPD Business Owner

eProc Project Team

ESC Project Mgr

Vendor

Oracle Team Vendor

SPD Functio

nal SME’s

and Users

FCD Vendor

File Maint. SME’s

and Users


Users

IV&V

Vendor

Project Control

Establish Controls

X X X

Project Process Review

X X X X X

Resource Management

Hire Project Manager

X X X

Hire IV&V Service

X X X

Procure Vendor Services

For Implementation

X X X

Contract Vendor Services

X X X X X

Funding

DoIT /PCC Approval for

– Planning Phase

X X X X X X

DoIT /PCC Approval for - Implementation Phase

X X X X X X

75


SPD Business Owner

eProc Project Team

ESC Project Mgr

Vendor

Oracle Team Vendor

SPD Functio

nal SME’s

and Users

FCD Vendor

File Maint. SME’s

and Users


Users

IV&V

Vendor

DoIT/ PCC Approval for – Closeout, Stabilization and Transition

X X X X X X

App/Tech Infrastructure.

Select Solution for implementation

X X X X X

Sign License Agreement, if needed

X X X X X

Acquire modules or Solution Package, if needed

X X X X X

Select implementation Vendor, if needed

X X X X X

Infrastructure Analysis & documentation of Design Specifications

X X X X X

Hardware/Software Procurement, if needed

X X X X X

Functionality Analysis & Design

x X X X X

76


SPD Business Owner

eProc Project Team

ESC Project Mgr

Vendor

Oracle Team Vendor

SPD Functio

nal SME’s

and Users

FCD Vendor

File Maint. SME’s

and Users


Users

IV&V

Vendor

Functional feature review and Customization

X X X X X

Disaster Recovery

Planning

X X X X X

Transition X X X X XBusiness Process Reengineering

Define X X X X X X XMeasure X X X X X X XAnalyze X X X X X X XImprove X X X X X X X XControl X X X X X X X XImplementation

Development & Design of configurations and optimizations

X X X X X X X X

Implementation Plan for Reengineered Business

X X X X X X X X X

77


SPD Business Owner

eProc Project Team

ESC Project Mgr

Vendor

Oracle Team Vendor

SPD Functio

nal SME’s

and Users

FCD Vendor

File Maint. SME’s

and Users


Users

IV&V

Vendor

Processes

Testing Plan and Resource assignments

X X X X X X X X X

Change Management Plan and Resource assignments

X X X X X X X X

Training Plan/Training Manuals and schedule Training

X X X X X X X X X

System Integration

X X X X X X X X X

Content Migration

X X X X X X

Move to Production

X X X X X X

Monitor and Control/Stabalization Period

X X X X X X X X

eProc Rules & Standards

eProc Framework

X X X X X X X

eProc Roadmap X X X X X X X

78


SPD Business Owner

eProc Project Team

ESC Project Mgr

Vendor

Oracle Team Vendor

SPD Functio

nal SME’s

and Users

FCD Vendor

File Maint. SME’s

and Users


Users

IV&V

Vendor

eProc Standards X X X X X X eProc Rules X X X X X XSupporting Organizational Infrastructure

Train Operational Staff

X X X X X X X

Train Admin Staff

X X X X X X X

Train End-Users X X X X X X X eProc User Group

X X X X X

eProc Governance Body

X X X X X X X X

At the conclusion of the Planning Phase for Phase II, we will create a table similar to the one above once assignments have been confirmed.

79

5.5.1 P5.5.1 PROJECTROJECT S STAFFTAFF

Resource

Wkly Committed Effort Estimate

Estimated Hours Availability Skill Set Work Product/Deliverable

Steering Committee

Arturo Jaramillo, Cab Sec

Marilyn Hill, Dep. Cab Sec Office Designee

Michael Vinyard, Div Dr.

John Prihoda, SHARE Proj Mgr

Anthony Armijo, DFA FCD Dir.

Karen Baltzley, GSD CIO

2 hrs/mo Attend monthly Project Executive Steering Committee Meetings

DFA Project Managers:

John Prihoda, SHARE

Susan Steinberg, SHARE

20% 8 hrs/wk 20% Project Oversight, Attend Team meetings, Certification Requests and TARC Review, SHARE system liaison

GSD CIO:

Karen Baltzley

5-10% 1-4 hrs/wk

5-10% Optional Project Team meeting attendance, attend Certification Requests and TARC Review. Liaison between multiple agencies and SPD Business Owners

Resource

Wkly Committed Effort Estimate


SPD Business Owner:

Ross Boom

50% 20 hrs/wk 50%

Contract Project Mgr:

Keith Campbell, Oracle Inc.

100% 40 hrs/wk 100% Del 1: Initial PMP

Del 2: Oversee and coordinate Oracle Health Check activities

Del 3: Update PMP

Del4: Project Management

SPD Subject Matter Experts

Kathy Sanchez

Gerrie Becker

100% 40 hrs/wk

(1 FTE equivalent)

100% Attend Team meetings, provide expertise for purchasing business and functional processes and requirements, Functional End user Testing, Data Integrity review,

Project Team:

Mike Vinyard, SPD (Advisor)

Ross Boom, SPD

Kathy Sanchez, SPD

Susan Steinberg, SHARE

John Prihoda, SHARE

Karen Baltzley, GSD (Advisor)

Marilyn Hill (Optional)

Pamelya Herndon (Advisor)

Jeffrey Granger (Advisor)

20-50% 8 hrs/wk min. and additional as needed

20-50% Attend Team meetings, participate as needed with Project Team tasks and activities

81

SPD Functional Lead: (1) 100% 40 hrs/wk

20/wk ea

80 manhours /wk

100% Purchasing Business Subject matter expert

Available to provide input ,subject matter intelligence, and participation throughout Development, Testing, Training, Rollout, Stabilization, and Close of A-Optimization implementation.

82

80 manhours /wk

10/wk ea

83

8 manhours /wk

4/wk ea

8 manhours /wk

4/wk ea

84

12 manhours /wk

6/wk ea

85

36 manhours /wk

6/wk ea

36 manhours /wk

6/wk ea

86

36 manhours /wk

6/wk ea

4hrs/wk

40 hrs/wk

87

SPD Testers: (8) 25% (av. June, July ‘09)

80 manhours /wk

25% (av. June, July ‘09)

Purchasing Business Subject matter expert

Work with Oracle to define business and workflow requirements for A-Optimizations, update UPK’s and prepare for UAT using the updated UPKs

SPD Super Users/Trainers (8)

25% (av. July, Aug, Sept, ’09)

80 manhours /wk

25% (av. July, Aug ’09)

Purchasing Business Subject matter expert

Work with Oracle and eProcurement Project Mgr to define business and workflow and re-engineered business processes for A-Optimizations, assist with updating UPKs, train SPD Func End Users, Support functional End Users after rollout and during stabilization period

FCD Vendor Maint. SME’s (2)

12% (av. May, June ’09)

8 manhours /wk

10% (av. May, June ’09)

FCD and Vendor File Maint. Subject Matter expert

provide input ,subject matter intelligence, and participation throughout Development, Testing,

FCD Testers (2) 12% (av. June, July ’09)

8 manhours /wk

10% (av. June, July ’09)


Work with Oracle to define business and workflow requirements for A-Optimizations, update UPK’s and execute UAT using the updated UPKs

FCD Super Users/Trainers (2)

12% (av. July, Aug, Sept, ’09)

8 manhours /wk

10% (av. July, Aug ’09)


Work with Oracle and eProcurement Project Mgr to define business and workflow and re-engineered business processes for A-Optimizations, assist with updating UPKs, train FCD and Agency POCs/End Users, Support FCD and Agency POCs/End Users after rollout and during stabilization period

Agency Purchasing SME’s (9)

12% (av. May, June ’09)

54 manhours /wk

10% (av. May, June ’09)

Agency level Purchasing Subject Matter Expert and SHARE User

provide input ,subject matter intelligence, and participation throughout Development, Testing

88

Agency Testers (9) 12% (av. June, July ’09)

54 manhours /wk

10% (av. June, July ’09)


Work with Oracle to define business and workflow requirements for A-Optimizations, update UPK’s and execute UAT using the updated UPKs

Agency Super Users/Trainers (9)

12% (av. July, Aug, Sept ’09)

54 manhours /wk

10% (av. July, Aug ’09)


Work with Oracle and eProcurement Project Mgr to define business and workflow and re-engineered business processes for A-Optimizations, assist with updating UPKs, train Agency Purchasing End Users, Support Agency Purchasing End Users after rollout and during stabilization period

IV & V Contractor: TBD TBD

Vendor Project Mgr: 10% 4hrs/wk 10%

Vendor Implementation LeadRichard Susanto

100% 40 hrs / wk 100% Lead Design, CRP, UAT activities.

Vendor Implementation UPK Resources

100% 40 hrs / wk 40 hrs / wk Design and build UPK content over a six week period.

The table above represented the team for Project Phase I (Optimization A). At the conclusion of Planning Phase activities for Phase II of ePro, we will present a new table below for that project.

5.5.2 N5.5.2 NONON-P-PERSONNELERSONNEL RESOURCESRESOURCES

Use this section to list services or product (HW/SW and such) needed for project.

This will be determined in Planning Phase and based on Health Check Recommendations

89

Resource Cost Estimate

Estimated units/hours Availability Source Work Product/Deliverable

5.6 PROJECT LOGISTICS5.6 PROJECT LOGISTICSLogistics describes how the project manager, project team, the business owner/customer and any vendor resources will physically work together. Include anything to do with moving or starting resources. Training specifically related to project team members should be included here.

Development Stage: The SPD Conference Rm, Montoya Bldg, Twill be the primary meeting location for eProcurement Team, Oracle Team, SPD, FCD and Agency SME’s. Note additional work and meetings during Development and CRP also took place at DFA’s old location at 810 San Mateo. This facility is where the contractors from Oracle worked, developed, created UPKs, held meetings and presented CRP.

Later in the project, DFA Development moved to a new location on 210 Montezuma.

Unit and QA Testing Stage: SHARE IT Support personnel will identify and advise Oracle developers and eProcurement PM of appropriate locations/desktops for Oracle use to access Development and Unit testing and QA regions.

UAT stage: SHARE IT Support personnel will set up test stations for UAT according to requirements submitted by eProcurement Project and advise eProcurement PM of locations and access specifications for testers. Note, UAT was conducted in accordance will plans in Training Room 2 of the Simms Building.

Regression Testing stage: SHARE IT Support will conduct Regression testing in QA test region and using SHARE System defined regression and integration scripts. Regression test plans have been validated and space is being considered as of 8/5/2009.

Training stage: SHARE IT Support personnel will set up training environment according per requirements submitted by eProcurement Project and advise eProcurement PM of locations and access specifications for trainers and trainees. Training content will be based on updated UPK’s

90

and re-engineered Business processes. Trainees will include Purchasing End Users from SPD, Agencies, SHARE IT Support personnel, FCD Vendor File Maintenance Users.

Follow up note, Training was conducted in person and virtual using the WIMBA tool. Surveys were distributed as part of the training activities and as of 9/30/2009, the results are being compiled and analyzed. Initial feedback regarding testing has been positive.

5.6.1 P5.6.1 PROJECTROJECT T TEAMEAM T TRAININGRAINING

Describe training if any needed by project team members. This is not to include training for end users, system administrators or business owners; those should be handled within a training document or part of the transition to operations planning.

The eProcurement Project Team members and identified SME’s and Super Users will be involved with Oracle during Development, updating of UPKs and Unit Testing of the each of the Optimizations that will be implemented and used by their end users. As a result, the SPD, FCD and Agency SME’s and Super Users will acquire understanding and familiarity with the Purchasing functionality or re-engineered Business processes. Their involvement in developing, UPK updating, and testing will equate to practical training for these personnel for the Optimizations being implemented. Project Team members, SME’s and Super Users will have the option of attending the End User Trainings.

ResourceCost Estimate


As a follow up, training was gained by the team on the job and did not require additional outside training (or costs).

For Phase II, we recommend that key members of the Project Team take available eProcurement classes before the start of the Implemention Phase.

91

6.0 PROJECT MANAGEMENT AND CONTROLS6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1 RISK AND ISSUE MANAGEMENTPMBOK©:

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.

6.1.1 R6.1.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

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.

6.1.2 P6.1.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION

The Initial Risk Assessment will be completed and documented by the Project Manager and Project Team. New Risks will be added and existing risks updated and tracked on the Risk Log throughout the project term.

6.1.3 P6.1.3 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH

Mitigation strategies will be identified for every project Risk. The Project Manager will advise the Team and Executive Sponsors if/when a Risk occurs, and the appropriate mitigation action will be selected and applied.

6.1.4 R6.1.4 RISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY

Reporting: The Project Manager is responsible for maintaining the Project Risk Log. Any project stakeholder can report Risks or changes to existing risks to the Project Manager or Project Sponsor. New reported Risks and/or changes to existing Risks will be reviewed weekly by the Project Manager and Project Team or as needed throughout the project lifetime. The Risk

92

Log will be updated monthly and included as part of the Monthly Project Status Report to Executive Steering Committee.

Escalation: The Project Manager will advise the SPD Business Owner, DFA Oversight and GSD CIO immediately of significant new Risks or changes to existing Risks. The SPD Business Owner and DFA Oversight will determine and direct the appropriate action and advise the GSD CIO of action being taken.

6.1.5 P6.1.5 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH

6.1.6 ISSUE MANAGEMENT6.1.6 ISSUE MANAGEMENT

With any project, no matter how comprehensive the planning process, issues arise that need to be addressed. This section of the project manual addresses how this process will be managed for the eProcurement project.When the project team identifies an issue, it will be added to a document called eProcurement Project Issues Log, which will be stored in the project library. An issue can also be identified by anyone affiliated with the project although the project team will be primarily responsible for tracking issues through to resolution. The project team will review the Issues Log twice a month. Issues, which could negatively affect the project, will be brought to eProc ESC attention according to the change control process in section 6.3.1. The process of tracking an issue is outlined here:

1) An issue is identified.2) It is added to the issue document, assigned an issue number with a brief explanation of the issue

and date entered.3) The issue and potential action to be taken is assigned to someone.4) As action is taken, it is noted with the issue.5) If possible, an estimated completion date is entered.6) Upon resolution of an issue, the actual completion date is noted with the resolution.

Listed below are examples of how an issue can be resolved:

An issue can become a task added to the project plan with proper approval, if new, or within scope of the project. See section 7.2 and 7.4 for further details of these processes.

It could be resolved by an action taken. A document can be created which addresses the issue. A resolution could create new issues that need to be addressed. A new policy could be created which addresses the issue.

93

The Project Manager and Project Team are responsible to resolve issues or follow-up to be sure decided action is applied to resolve an issue.

6.1.6.1 Internal Issue Escalation and Resolution ProcessThis internal process is provided for issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality. This process should be used for improving project processes as the project is executed and where the implementation of such improvements should not be postponed to Lessons Learned during Project Close.

All Issues will be reported to the Project Manager as quickly as possible. The Project Manager will monitor Project Health and identify, report and address issues, as a routine project management activity. Whenever possible, the Project Manager will analyze identified issues, determine solutions and impacts with the appropriate project stakeholders and apply solutions at the lowest operational level possible. When an issue cannot be resolved at the Project Manager level, the Project Manager will escalate the issue to the SPD Business Sponsor for decision and/or direction. The Project Manager will be responsible for maintaining the Issue Log and keeping Executive Sponsors and Executive Steering Committee members informed of current status for all project Issues and Risks.

The Project Manager will be responsible for judging the severity of an issue and its potential impact to the project schedule, scope and budget. The Project Manager will keep Executive Sponsors and Steering Committee informed of Issues that pose significant impact to the project schedule, scope or budget. The Project Manager will coordinate with Executive Sponsors and Executive Steering Committee for issues/solutions that require Executive approval, decision or carries a cost.

This internal process will provide the mechanism for addressing issues that involve project resources, processes, procedures, or methodology that should be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality. This process will be used for improving project processes as the project is executed and where the implementation of such improvements should not be postponed to Lessons Learned during Project Close.

6.1.6.2 External Issue Escalation and Resolution ProcessThe external process is provided for issues that involve project resources, processes, procedures, or methodology that cannot be resolved within the Division that is responsible for managing the project without affecting the overall project schedule, cost, or quality.

94

If an Issue that poses significant impact to the project is not able to be resolved by the project Manager at the lowest operational level, the Project Manager will alert Executive Sponsors and Agency decision makers and enlist their support and direction to resolve. Executive Sponsors will take necessary steps with appropriate stakeholders to direct priority attention of project resources, processes, procedures, or methodology within a division so the issue can be resolved quickly with the least affect on the overall project schedule, cost, or quality.

6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V Independent Verification and Validation (IV&V) agent will evaluate the processes, methods, deliverables to determine compliance with specified requirements and the process of determining whether the products of a given development phase fulfill the requirements established during the previous stage, both of which are performed by an organization independent of the development organization.

6.3 SCOPE MANAGEMENT PLAN6.3 SCOPE MANAGEMENT PLANDescribe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations.

6.3.1 C6.3.1 CHANGEHANGE C CONTROLONTROL

6.3.1.1 Change Control ProcessChange Control establishes how change will be managed, including capturing, tracking, communicating, and resolving change. Due to much ambiguity regarding change, it is vital that we document and discuss the change process with the executive sponsor.

All Change Requests are to be submitted to the Project Manager on the eProcurement Change Request form. Maintaining the Change Request Log will be the responsibility of the Project Manager. For the Change Request Form refer to Appendix F: Change Request form

eProcurement Project Change Request Log will be monitored and processed as a function of regular Project Management and Status reporting.

95

6.3.1.2 Change Control Board (CCB)

Change Request is submitted and documented by Project Manager

Project Manager adds the Change Request and tracks on the Project Change Request Log.

Project Manager, Team members, and SPD Business Owner reviews the Change requested and makes recommendation.

SPD Business Owner takes Change Request and Team Recommendation to Executive Sponsors for approval.

Approved Change Requests with costs will follow established budgetary and purchasing processes and documented and tracked on the Change Request Log and Project Budget Report.

Approved Change Requests without costs will be documented and tracked on the Change Request Log.

The project scope and schedule will be adjusted as necessary to reflect approved Changes.

SHARE Change Control process for Development Requests, technical standards and guidelines, modifications, and migrations.

6.4 PROJECT BUDGET MANAGEMENT6.4 PROJECT BUDGET MANAGEMENTCosts estimates are the costs applied to an activity in a project by assigning resources with associated rates or fees. Resources can include equipment, material, technology, processing cycles, or people. The total cost is critical and should be consistent with the proposal; include breakdowns as needed. Match these cost estimates with the actual billed amounts. Use an appropriate format for the project size and customer requirements (e.g., by WBS, milestone, or deliverable).

6.4.1 B6.4.1 BUDGETUDGET T TRACKINGRACKING

The Project Manager will gather budget updates from DFA SHARE Project Sponsors and SPD Business Owners. The budget information and updates will be tracked and included as part of the Monthly Project Status Reports, Executive Steering Committee Status Reports and DoIT Monthly report.

96

6.5 COMMUNICATION PLAN6.5 COMMUNICATION PLANCommunication planning involves determining the information and communication needs of the stakeholders, executive sponsors, project team and others as needed. The communication plan needs to address who needs what information, when they will need it, how it will be given to them, and by whom. The complexity of the project may require a separate communication plan; however a high level summary of that plan will need to be included here and a reference made to the appropriate Appendix.

6.5.1 C6.5.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

What Who/Target Purpose When/Frequency Type/Method(s)

Initiation Meetings

All stakeholders*

Gather information for Initiation Plan

Before Project Start Date

Meeting

Distribute Project Initiation Plan

All stakeholders*

Distribute Plan to alert stakeholders of project scope and to gain buy in.

Before Kick Off Meeting

Before Project Start Date

Document distributed electronically and posted on project website

Project Kick Off

All stakeholders*

Communicate plans and stakeholder roles/responsibilities.

At or near Project Start Date

Meeting

Status Reports All stakeholders

Update stakeholders on progress of the project.

Monthly Distribute electronically and posted on project website. DoIT format as well as supplemental

97


Operations/Project Team Meetings

Entire Operations/

Project Team.

Individual meetings for sub-teams, technical team, and Functional teams as appropriate.

To review detailed plans (tasks, assignments, and action items).

Regularly Scheduled.

Weekly or bi-weekly as appropriate.

Meeting

Steering Committee Meetings

Steering Committee Project Manager

Update Steering Committee on status and discuss critical issues. Work through issues and change requests here before escalating to the Sponsor(s).

Monthly Meeting/Presentation

Executive Sponsor Meetings

Executive Sponsor(s) and Project Manager

Update Sponsor(s) on status and discuss critical issues. Seek approval for changes to Project Plan.

Not regularly scheduled.

As needed when issues cannot be resolved or changes need to be made to Project Plan.

Meeting

98


Audit/Review IV&V Contractor, DoIT,

Project Director, Project Team

Review status reports, issues, and risks. To identify and communicate potential risks and issues that may affect the schedule, budget, or deliverables.

Scheduled by IV&V contractor and by DoIT for project certification phase approvals and presentations.

Meeting/Report

Using DoIT required format

Post Project Review

Project Manager, key stakeholders, and sponsor(s).

Identify improvement plans, lessons learned, what worked and what could have gone better. Review accomplishments.

End of Project Meeting/Report

Project Manager will produce report using DoIT required format.

Monthly Project Review

Project Team, Project Director Project Manager, and key stakeholders.

Review overall health of the project and highlight areas that need action.

Monthly Meeting/Report

Presentations to Special Interest Groups

Examples:

LFC, DFA etc.

To update external groups to promote communication a create awareness of project interdependencies.

At project milestones so as to communicate with other interested parties of changes that will be introduced outside of the Project Team.

Presentation/Demonstration

99


Web Site ALL Project Team Members.

Central location to house Status Reports, meeting minutes, Project description, and Project Plan. For any communications that can be shared with all staff.

Update weekly with Status Reports; otherwise, as necessary.

Electronic Communications Venue

User Updates/Status

SPD Staff General communications

At weekly staff meeting

Meeting/Demonstrations

Other… To be determined by the Project Team

General communications

As needed

6.5.2 S6.5.2 STATUSTATUS M MEETINGSEETINGS

6.5.3 P6.5.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)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.

100

6.6.1 B6.6.1 BASELINESASELINES

Will be documented by Project Manager, assisted by the Project Team, and maintained in Project Office.

6.6.2 M6.6.2 METRICSETRICS L LIBRARYIBRARY

Will be documented by Project Manager, assisted by the Project Team, and maintained in Project Office.

6.7 QUALITY OBJECTIVES AND CONTROL6.7 QUALITY OBJECTIVES AND CONTROLQuality 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.

6.7.1 6.7.1 QUALITYQUALITY S STANDARDSTANDARDS

No. Quality Standard Tracking Tool or Measure

1 Project phase is completed by the established finish date. • Project Schedule• Project Status

2 Project is completed within budget. • Project Charter• Project Status

3 Quarterly project reviews show contractors deliver requirements specified in the contract by due dates or pay penalties.

• Vendor Contract• Final Customer

Acceptance

4 Project issues are resolved and documented within 10 calendar days of identification or extensions are justified.

• Issues Tracking

5 Project will be completed based on the original project scope and approved scope changes.

• Project Charter• Project Plan• Control Change

Request

6.7.2 P6.7.2 PROJECTROJECT ANDAND P PRODUCTRODUCT R REVIEWEVIEW AND ASSESSMENTS AND ASSESSMENTS

The methods for Product Review and Assessment will be identified and detailed in the Planning Phase and based on the Purchasing Health Check

101

Review Type Quality Standard Tools Reviewer Reports

Requirements

Plans

Milestones

6.7.3 A6.7.3 AGENCYGENCY/C/CUSTOMERUSTOMER S SATISFACTIONATISFACTION

The project manager should assess the on-going sense of the customer agency about how they feel the project is going, and how team members are acting on the project. This feedback would be helpful to the success of the project and the professional growth of the project team members.

Examples:

Areas of feedback When How Often

Agency awareness Business Owner Meetings Weekly

Quality of communications ESC Steering committee meetings

Monthly

Manages project tasks ESC Steering committee meetings

Monthly

Productive Meetings ESC Steering committee meetings

Quarterly

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESSHow the client takes procession of the product. Delivery of media; manuals; contracts; licenses; services agreements; configuration settings; status of patches to COTS products; in-house or vendor developed code; test cases, routines, and scripts; and other items required to operate the product.

Upon notification that a deliverable or work product is completed, the eProcurement Project Team will review and certify that Deliverable artifacts and/or outcomes are complete, sufficient to satisfy requirements, contract scope of work, contract terms and conditions, as appropriate. The eProcurement Team will its recommendation to Accept or Reject the deliverable, in writing

102

to DFA Oversight for payment of invoices and, in the case of a vendor Deliverable, notify the vendor in writing of reasons for rejection.

Deliverable Final Approval Process Customer Acceptance Criteria

Implementation Phase 1)eProcurement Team Certification and Acceptance Recommendation 2)Steering Committee Acceptance Sign Off

Per contract SOW, Terms and Conditions

Oracle Development of A-Optimizations and solutions, and updating of UPKs. for P2, S6/P6a, P10, S1, S2, S3, C1a, C1b, C2,

1)eProcurement Team Certification and Acceptance Recommendation 2)Steering Committee Acceptance Sign Off


IV&V Services : Assessments, periodic reporting, Project close assessment and summary report.



Project Mgmt Del 1: Oversee eProcurement Project Planning and Implementation Activities of the GSD



Project Mgmt Del 2: Update PMP 1)eProcurement Team Certification and Acceptance Recommendation 2)Steering Committee Acceptance Sign Off


Project Mgmt Del 3: Provide Project Documentation for eProcurement Planning and Implementation Phases



Project Mgmt Del 4: Prepare Project Close-out documents

1)eProcurement Team Certification and Acceptance Recommendation 2)Steering Committee Acceptance Sign off


6.8 CONFIGURATION MANAGEMENT6.8 CONFIGURATION MANAGEMENT

103

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.

During the eProcurement Implementation Phase, all Technical configuration documents developed by Oracle and the eProcurement Team efforts will be owned by SPD and made available to the SHARE system administration and technical support. Project information and documents will be stored in the eProcurement Project SHAREPOINT site, hosted by POD, Inc. and maintained by eProcurement PM for the term of the project. All eProcurement Team members, Executive Sponsors, and identified SHARE IT Support staff involved with this implementation will be provided access privilege to view and download copies of any project and configuration documents, as appropriate.

After the Project term, all the eProcurement documents and configuration and design documents will be owned and managed and maintained by GSD/SPD and SHARE System Administration and SHARE IT Support division.

6.8.1 V6.8.1 VERSIONERSION C CONTROLONTROL

6.8.2 P6.8.2 PROJECTROJECT R REPOSITORYEPOSITORY (P (PROJECTROJECT L LIBRARYIBRARY))“Provide to the Department all project management and product deliverables. Deliverables shall include but not limited to the project plan, project schedule, initial and periodic risk assessments, quality strategies and plan, periodic project reports, requirements and design documents for entire project. The lead agency must make available all deliverables in a repository with open access for the Department to review” PROJECT OVERSIGHT PROCESS Memorandum.

eProcurement Project Repository will be the SHAREPOINT site, hosted by POD, Inc. GSD CIO will have access to the eProcurement Project SHAREPOINT site and will take necessary steps to download eProcurement information files and documents to GSD network drive and project repository.

6.9 PROCUREMENT MANAGEMENT PLAN6.9 PROCUREMENT MANAGEMENT PLANProjects often have some element of procurement, i.e. the requirement to purchase goods and/or services from outside the organization. The procedures to be used to handle these procurements should be included here. Activities such as a make-or-buy analysis; writing requirements;

104

solicitation planning, evaluation and selection; inspection and acceptance; contract closeout should all be included.

All procurement for project goods and services will be performed under the guidance and direction of New Mexico State Procurement Statues, which will be made available by GSD SPD.

7. 0 PROJECT CLOSE7. 0 PROJECT CLOSEProject Close will always consist of administrative project activities and possibly contractual project activities and an external vendor is employed. Completing both sets of activities is a mandatory step in the project life cycle. Administrative activities complete the internal needs for the Agency/Unit that is responsible for managing the project, such as lessons learned, recording the last hours against the project, and providing transition for the staff to other assignments. Contractual activities meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products.

7.1 A7.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE

Administrative Close occurs at both the end of phase and end of project. This closure consists of verification that objectives and deliverables were met. Acceptance is formalized and phase activities are administratively closed out. Administrative closure occurs on a “by-phase” basis in accordance with the WBS and should not be delayed to project end. At that point, the burden of closing is too great and audits inaccurate. The specific project close activities for a given project are contingent on the project’s complexity and size. Project managers should work with the project’s project management consultant to tailored Project Close procedures to compliment the project’s objectives

7.2 C7.2 CONTRACTONTRACT C CLOSELOSE

Contract close is similar to administrative close in that it involves product and process verification for contract close.

The eProcurement Project Manager is responsible for 1)documenting outcomes and tracking completion of all eProcurement Project activities, tasks, milestones and deliverables and 2)preparing all project close documents, as required by DoIT, DFA, GSD.

105

ATTACHMENTSATTACHMENTSAttachments are included for additional information, but are not formally considered part of the Project Plan for approvals and change management purposes. Examples

Attachment A: Project Schedule with Milestone and Tasks

Attachment B: Risk Assessment

Attachment C: Risk and Issue Log

Attachment D: Change Request Log

Attachment E: DFA/GSD Memorandum of Understanding for eProcurement

Attachment F: Project forms/Templates

Issue Report form

Risk Report form

Change Request form

Attachment G: Project Budget

Attachment H: Project Library

Attachment I: Project Acronyms

Attachment J: Project Management Definitions

Attachment K: eProcurement Test Strategy

Attachment L: eProcurement Training Strategy

106

AATTACHMENTTTACHMENT A: P A: PROJECTROJECT S SCHEDULECHEDULE WITHWITH M MILESTONESILESTONES ANDAND T TASKSASKS

For a soft copy of the most current eProcurement MS Project schedule and Gantt, contact Keith Campbell, Project Manager, [email protected]

107

AATTACHMENTTTACHMENT B: R B: RISKISK A ASSESSMENTSSESSMENT R REPORTEPORT

108

EPROCUREMENTEPROCUREMENT ANDAND S STRATEGICTRATEGIC S SOURCINGOURCING PPROJECTROJECT

PROJECT RISK ASSESSMENTPROJECT RISK ASSESSMENT

EXECUTIVE SPONSOR – ARTURO JARAMILLO, CABINET SECRETARY

BUSINESS OWNER – ROSS BOOM, SPD

PROJECT MANAGER – JODY BLEST, POD INC.

ORIGINAL DATE: JANUARY 20, 2009REVISION DATE: AUGUST 6, 2009

REVISION: 2.6

109



1.0 December 22, 2008 eProcurement Initial Risk Assessment draft

2.0 January 20, 2009 Revisions from eProcurement Team input

2.1 January 29, 2009 Revisions from eProcurement Team.

2.2 January 30, 2009 Submitted with eProcurement Initial PMP Project Mgmt Del. 1.

2.3 February 12, 2009 Revised and submitted with eProcurement Initial PMP v 1.1.3

2.4 February 16, 2009 Revisions from eProcurement Team

2.5 March 31, 2009 Updated Risk Assessment for Implementation Phase

2.6 August 6, 2009 Additional Risks added from Log.

Please update file name to reflect document version number when submitting it to DoIT.

110

Table of ContentsREVISION HISTORY.......................................................................................................................................... 106

RATIONALE -PROJECT RISK ASSESSMENT REPORT – PROJECT INCEPTION.........................................................108

Department of information technology requirement.........................................................................................108Risk Assessment and Risk management..............................................................................................................108

RISK EVALUATION FOR THIS PROJECT..............................................................................................................109

IMPACT RISK................................................................................................................................................... 109

Project Organization Risks...................................................................................................................................110Requirement Risks...............................................................................................................................................112Technical Risks....................................................................................................................................................113Planning Risks......................................................................................................................................................114

INITIAL RISKS IDENTIFIED IN PROJECT CHARTER AND/OR PROJECT MANAGEMENT PLAN.................................114

Instructions for completing the risk identification table.....................................................................................114Risk 1: Inadequate Funding.................................................................................................................................115Risk 2: Inadequate personnel..............................................................................................................................115Risk 3: Outsourced Vendor / Solution.................................................................................................................116Risk 4: Inconsistencies of Procurement Transactions between modules............................................................116Risk 5: Ineffective training for Purchasing Staff...................................................................................................117

ATTACHED PROJECT RISK LOG – AFTER INITIAL ASSESSMENT...........................................................................118

RISK CALCULATION EXAMPLE.......................................................................................................................... 118

eProcurment Project Initial Risk Assessment and Rating................................................................................119

111

RATIONALE -PROJECT RISK ASSESSMENT REPORTRATIONALE -PROJECT RISK ASSESSMENT REPORT Risk: “An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives. PMBOK©:

DEPARTMENT OF INFORMATION TECHNOLOGY REQUIREMENTDEPARTMENT OF INFORMATION TECHNOLOGY REQUIREMENT“Prepare a written risk assessment report at the inception of a project and at the end of each product development lifecycle phase or more frequently for large and high-risk projects. Each risk assessment shall be included as a project activity in the project schedule. “PROJECT OVERSIGHT PROCESS memorandum

RISK ASSESSMENT AND RISK MANAGEMENTRISK ASSESSMENT AND RISK MANAGEMENT• Project Management is Risk Mitigation. It is about how we create and manage a

temporary organization to deliver the unique product, service or result!

• Project Management by providing structure to the temporary organization and the solution development/deployment process reduces the risk of counterproductive chaos.

• By communicating Risks with stakeholders we keep them in the loop, and often involve them in risk mitigation or lessening its impact

• By acknowledging that there is risk, we can structure ways of avoiding or effectively dealing with specific risk.

112

RISK EVALUATION FOR THIS PROJECTRISK EVALUATION FOR THIS PROJECTIMPACT RISKIMPACT RISK

Risk Yes No Provide an Explanation/Comment

Has the project leadership read and planned for compliance with the DoIT Project Oversight Memorandum and Project Certification Memorandum?

Have all the cost impacts to the agency/state been documented

Has the impact to daily operations been documented

Have the impacts to existing processes been documented

Have the schedule impacts to state or agency activities been identified?

Have the benefits of the project been fully identified?

Project Charter

Will the project require funding beyond that originally allocated to the project?

This will be a multi-year, multi-phase project

Has the project included the State procurement Processes and time frames as well as the Project certification/release of funds process in its schedule planning?

Multi-year, multi-phase project

113

PROJECT ORGANIZATION RISKSPROJECT ORGANIZATION RISKS


Has sufficient funding been approved for the project

This will be a multi-year, multi-phase project. Each phase will depend on amount of funding available

Has a qualified project manager been assigned to the project

Does the qualified project manager have sufficient time to manage the project?

Has the project identified All relevant stakeholders?

Is the scope of the project within the agency mission

Are there business owners assigned to the project who have the time and understood responsibilities for the project?

SPD has dedicated 1 employee fulltime equivalent with additional employees available as SME’s, Super Users, Testers.

Has a project steering committee been established within a project governance plan?

Is there adequate agency staffing resources made available for the project?

SPD resources identified for Implementation Phase. Project Team will monitor and resource adequacy and availability and report any resource issues according to Issue reporting protocol

114

Is there a “change management” process established?

To be developed and executed by eProcurement Team, SPD, FCD, Agency SME’s, Super Users. During the Development stage.

115

REQUIREMENT RISKSREQUIREMENT RISKS


Has the project team documented the initial business requirements for the project beyond the business objectives listed in the project charter?

Have the stakeholders approved all documented business requirements?

Are documented requirements defined in measurable terms?

Are requirements prioritized – i.e. essential, conditional, or optional?

Has an initial impact analysis been performed on the business requirements – i.e., cost, operations, support

Is there a well defined and institutionalized change control process for requirements?

To be developed by SPD and eProcurement Team during Development stage, modeled after and aligned with existing SHARE system change control process.

Has the project established the ability to verify that business requirements can be traced through technical design, system building or software coding/ configuration and test phases to verify that the system performs as intended and contains no unnecessary elements?

116

TECHNICAL RISKSTECHNICAL RISKS


Is the project planning to use an existing technology?

Is the project planning to implement a COTS (Commercial Off the Shelf”) solution?

This will be a SHARE Solution.

If COTS solution is anticipated will it require significant customization, other than built in set-up/start up configurations

To be determined as part of Health Check

Does the agency or State (DoIT) have experience with the underlying technology or hardware/operating system environment?

SHARE is an installed enterprise application.

Is a test environment part of the project or is there an existing test environment that mirrors the production environment?

Is there at least a tentative plan for Business Continuity?

SPD is in process of developing. Will rely on Health Check recommendations and A-Optimization purchasing improvements and solutions being implemented.

117

PLANNING RISKSPLANNING RISKS

Risk Yes No IF No – Provide an Explanation

Does the plan include the appropriate time and cost contingency?

Does the plan include the appropriate time and cost estimates?

Has a product planning methodology been chosen appropriate for the complexity of the solution and the knowledge of the project team?

Has the project adequately identified the constraints and assumptions of the project?

Has the project adequately identified the project risks, with probability, impact, mitigation and or contingencies?

Are there significant dependencies on other projects or staff resources?

Dependent on SHARE project and SHARE Resources

INITIAL RISKS IDENTIFIED IN PROJECT CHARTER AND/ORINITIAL RISKS IDENTIFIED IN PROJECT CHARTER AND/OR PROJECT MANAGEMENT PLANPROJECT MANAGEMENT PLAN

INSTRUCTIONS FOR COMPLETING THE RISK IDENTIFICATION INSTRUCTIONS FOR COMPLETING THE RISK IDENTIFICATION TABLETABLE

Risk Name – should easy reflect the challenge without detail

Description - Describe the risk’s characteristics and explain why this risk is perceived to have the potential to affect the outcome of the project.

118

Probability and Impact - - Probability should be measured as the likelihood of that the risk will occur. Impact should be measured in terms of deviations from the schedule, effort, or costs from the schedule if risks occur.

Probability Levels: Certain, Expected, Likely, Possible, Unlikely

Impact Levels: Very High, High, Medium, Low, Very LowMitigation Strategy - Identify what actions can be taken in order to reduce the probability of the risk, or to reduce its impact on the project.Contingency Plan Identify what actions will be taken when the risk materializes and threatens the scope, budget, or the schedule of the project.

RISK 1: INADEQUATE FUNDINGRISK 1: INADEQUATE FUNDING Description - Insufficient funds appropriated to support this project

Probability: POSSIBLE Impact: LOW 1) May be forced to implement procurement functionality in a phased manner. 2) SPD may be unable to meet statutory requirements, 3) customer agency needs may not be completely met, and 4) procurement efficiency will be negatively impacted

Mitigation Strategy: Need to prioritize required functionality and focus efforts on highest impact areas. Contingency Plan: Worst case, status quo continues; Most likely case, implement a subset of functionality. SPD may be required to assign personnel to cover gaps in system/tool availability

RISK 2: INADEQUATE PERSONNELRISK 2: INADEQUATE PERSONNELDescription- Lack of adequate personnel to support the eProcurement Project effort.

Probability: POSSIBLE Impact: LOW that schedules will be delayed, costs may increase and project may not receive the thought and testing required for smooth transition into production/implementation Surprises may occur during the initial go-live period

Mitigation Strategy: Ensure adequate trained personnel are enlisted to support the effort up front. Realistically develop schedule and identify potential outsource opportunities i.e. Project Management, consultants, software configuration, etc.

119

Contingency Plan: Identify scope priorities and schedule slippage opportunities. Monitor closely the workload and personnel assignments. Utilize outside resources if budget will accommodate

RISK 3: OUTSOURCED VENDOR / SOLUTIONRISK 3: OUTSOURCED VENDOR / SOLUTION Description Outsourcing project implementation

Probability: EXPECTED Impact: LOW System may not fully meet needs. Costs are increased.

Mitigation Strategy: Ensure dedicated Project Manager resource. Must closely monitor and manage outside implementation team. Perform regular validation reviews to ensure implementation assumptions used by third party are consistent with user organization(s) as well as track progress to identify issues that may cause schedule delays and cost overruns. If schedules start to slip, apply additional resources and/or re-focus vendor priorities. Monitor cost incurrence closely. Structure the third party agreement to incentivize schedule adherence, cost control, and resultant system performance.Contingency Plan: Monitor situation closely and utilize all functionality available. Worst case: Status quo continues, unable to fully meet statutory requirements, serve customers, and procurement bottleneck. SPD may be required to assign personnel to cover gaps in system/tool availability

RISK 4: INCONSISTENCIES OF PROCUREMENT TRANSACTIONS RISK 4: INCONSISTENCIES OF PROCUREMENT TRANSACTIONS BETWEEN MODULESBETWEEN MODULES

Description Financial handling of procurement transactions in current SHARE system may have deviated from the “boiler” assumptions that are built into the procurement modules

Probability: POSSIBLE Impact: LOW the Procurement transactions may be tracked in the financial system inconsistently and/or incorrectly

Mitigation Strategy: Rely on Health Check to identify areas deviated from the boiler plate assumptions and make recommendations for handling. Substantial testing of the procurement (related) modules of PeopleSoft for financial handling/results will be necessary to identify if problems exist with current financial flows and those built into the modules.

120

Contingency Plan: In event financial transactions are inconsistent between the modules, delay of migration to the production environment may be necessary until such time resolution and consistency are available. SPD may be required to assign personnel to cover gaps in system/tool availability

RISK 5: INEFFECTIVE TRAINING FOR PURCHASING STAFFRISK 5: INEFFECTIVE TRAINING FOR PURCHASING STAFFDescription – Inadequate or ineffective training for Central Purchasing and Agency Staff.

Probability: POSSIBLE Impact: LOW Improvements and enhancements to current PeopleSoft (SHARE) system purchasing functionality will not be realized. Transition or change management will be more difficult because of user errors. Increased User trouble tickets and demand on SHARE technical support staff.

Mitigation Strategy: Identify Training needs, end users who need training. Standardize procedures for all Central Purchasing and Agency Purchasing end users. Identify “Super Users” from the Central Purchasing, Agency and Tech Support User community who will be trained. Engage “Super Users” with the eProcurement Team in developing of comprehensive training plan to provide training on Purchasing modules, functions and procedures. Ask Oracle to include recommendations for training specific to their recommendations for improvements and road forward for the People Soft (SHARE) system and consider contracting Oracle Trainers to provide specific training for State of NM Purchasing “Super Users” and others, as possible.

Update and utilize existing UPK Training facilities for training end users.

Contingency Plan: Identify Super Users at Central Purchasing and each Agency who will be responsible to train end users at their location or unit. These Super Users will also be responsible for providing first level End user support on Purchasing functions and procedures to end users in their location. Develop Training materials and webinars and make available to Purchasing and Agency end users.

RISK 6: LOSS OF PROJECT MANAGER UNDER POD PROFESSIONAL RISK 6: LOSS OF PROJECT MANAGER UNDER POD PROFESSIONAL SERVICES CONTRACTSERVICES CONTRACT

Probability: CERTAIN Impact: HIGH

121

Loss of Project Manager under POD Professional Services Contract

Mitigation Strategy: Contract with Oracle to provide Project Management planning and oversight for the testing and training phases of the project. It is too late in the project life cycle to bring in another project manager who is not already familiar with the project.

Contingency Plan: Ensure that e-Procurement Project Team works with Oracle to manage balance of the project and begin planning for the next phase -- Optimization B

ATTACHED PROJECT RISK LOG – AFTER INITIAL ATTACHED PROJECT RISK LOG – AFTER INITIAL ASSESSMENTASSESSMENT

After the initial project risk assessment, please attach the project’s Risk Log with the revised reports during the product development phases as per:

“Prepare a written risk assessment report at the inception of a project and at the end of each product development lifecycle phase or more frequently for large and high-risk projects. Each risk assessment shall be included as a project activity in the project schedule. “PROJECT OVERSIGHT PROCESS memorandum

The DoIT Risk and Issues Log Template should be used by projects to track risks and report them to DoIT as required by the Project Oversight Process.

RISK CALCULATION EXAMPLERISK CALCULATION EXAMPLEThis is a table from the DoIT Risk and Issues Log Template spreadsheet that calculates Risk

Probability Levels: Certain, Expected, Likely, Possible, Unlikely

Impact Levels: Very High, High, Medium, Low, Very LowThe DoIT Risk and Issues Log Template uses these calculations for Probability and Impact which are usually hidden fields.

Number Risk Probability Impact Rating Probability Impact1 Risk Certain Very High 0.9025 0.95 0.95

2 Risk Expected High 0.5625 0.75 0.753 Risk Likely Medium 0.3025 0.55 0.55

122

4 Risk Possible Low 0.1225 0.35 0.35

5 Risk Certain High 0.7125 0.95 0.75

6 Risk Expected Medium 0.4125 0.75 0.55

7 Risk Likely Low 0.1925 0.55 0.358 Risk Unlikely Very Low 0.0225 0.15 0.159 Risk Certain Low 0.3325 0.95 0.35

10 Risk Certain Very Low 0.1425 0.95 0.1511 Risk Expected Medium 0.4125 0.75 0.5512 Risk Expected Low 0.2625 0.75 0.3513 Risk Possible Very High 0.3325 0.35 0.9514 Risk Likely High 0.4125 0.55 0.7515 Risk Possible Medium 0.1925 0.35 0.5516 Risk Likely Medium 0.3025 0.55 0.55

Legend: Minimum risk - Acceptable Some risks - Monitor at PM/Team Level High risks - Active monitoring with ongoing Contingency/Mitigation activity Show stoppers - Active participation with steering committee to mitigate

EEPPROCURMENTROCURMENT P PROJECTROJECT R RISKISK A ASSESSMENTSSESSMENT ANDAND R RATINGATING

Number Risk Probability Impact Rating Probability Impact1 Risk: Inadequate Funding Possible Low 0.1225 0.55 0.75

2 Risk: Inadequate Personnel

Possible Low 0.1225 0.55 0.75

3 Risk: Outsourced Vendor / Solution

Expected Low 0.2625 0.75 0.35

4 Risk: Inconsistencies of Financial Transactions between modules

Possible Low 0.1225 0.55 0.75

5 Risk: Ineffective Training for Purchasing staff

Possible Low 0.1225 0.55 0.75

123

Certain 0.95 Very High 0.95

Expected 0.75 High 0.75Likely 0.55 Medium 0.55

Possible 0.35 Low 0.35Unlikely 0.15 Very Low 0.15

6 Loss of Project Manager Certain High

Legend:

Minimum risk - AcceptableSome risks - Monitor at PM/Team LevelHigh risks – Active monitoring with ongoing Contingency/Mitigation activity

Show stoppers - Active participation with steering committee to mitigate

124

AATTACHMENTTTACHMENT C: R C: RISKISK ANDAND I ISSUESSUE L LOGOG

For a copy of the most current eProcurement Risk and Issue Log, contact keith Campbell, Project Manager, [email protected].

No. Risk Probability Impact Rating Contingency Plan Mitigation Plan1 INADEQUATE FUNDING

Inadequate Funding Possible Low 0.1225 Worst case, status quo

continues; Most likely case, implement a subset of functionality. SPD may be required to assign personnel to cover gaps in system/tool availability

Need to prioritize required functionality and focus efforts on highest impact areas.

2 INADEQUATE PERSONNEL Lack of adequate personnel to support the eProc Project effort.

Possible Low 0.1225 Identify scope priorities and schedule slippage opportunities. Monitor closely the workload and personnel assignments. Utilize outside resources if budget will accommodate

Ensure adequate personnel are enlisted to support the effort up front. Realistically develop schedule and identify potential outsource opportunities i.e. Project Management, consultants, software configuration, etc.

3 OUTSOURCED VENDOR / SOLUTION Outsourcing project implementation

Expected Low 0.2625 Monitor situation closely and utilize all functionality available. Worst case: Status quo continues, unable to fully meet statutory requirements, serve customers, and procurement bottleneck. SPD may be required to assign personnel to cover gaps in system/tool availability

Ensure dedicated Project Manager resource. Must closely monitor and manage outside implementation team. Perform regular validation reviews to ensure implementation assumptions used by third party are consistent with user organization(s) as well as track

125

mailto:[email protected]

progress to identify issues that may cause schedule delays and cost overruns. If schedules start to slip, apply additional resources and/or re-focus vendor priorities. Monitor cost incurrence closely. Structure the third party agreement to incentivize schedule adherence, cost control, and resultant system performance.

4 INCONSISTENCIES OF FINANCIAL TRANSACTIONS BETWEEN MODULES Financial handling of procurement transactions in current SHARE system may have deviated from the “boiler” assumptions that are built into the procurement modules

Possible Low 0.1225 In event financial transactions are inconsistent between the modules, delay of migration to the production environment may be necessary until such time resolution and consistency are available. SPD may be required to assign personnel to cover gaps in system/tool availability

Substantial testing of the procurement (related) modules of PeopleSoft for financial handling/results will be necessary to identify if problems exist with current financial flows and those built into the modules

5 INEFFECTIVE TRAINING FOR PURCHASING STAFF Inadequate or ineffective training for Central Purchasing and Agency Staff.

Possible Low 0.1225 Identify Super Users at Central Purchasing and each Agency who will be responsible to train end users at their location or unit. These Super Users will also be responsible for providing first level End user support on Purchasing functions and procedures to end users in their location. Develop Training materials and

Identify Training needs, end users who need training. Standardize procedures for all Central Purchasing and Agency Purchasing end users. Identify “Super

126

webinars and make available to Purchasing and Agency end users.

6 Loss of Project Manager under POD Professional Services Contract

Certain High 0.7125

Contract with Oracle to provide Project Management planning and oversight for the testing and training phases of the project. It is too late in the project life cycle to bring in another project manager who is not already familiar with the project.

Ensure that e-Procurement Project Team works with Oracle to manage balance of the project and begin planning for the next phase -- Optimization B

Legend:

Minimum risk - Acceptable Some risks - Monitor at PM/Team Level

High risks - Active monitoring with ongoing Contingency/Mitigation activity

Show stoppers - Active participation with steering committee to mitigate

127

AATTACHMENTTTACHMENT D: C D: CHANGEHANGE R REQUESTEQUEST L LOGOG

For a copy of the most current eProcurement change Request Log, contact Keith Campbell, Project Manager, [email protected]

128

CCHANGEHANGE R REQUESTEQUEST L LOGOG

PROJECT: GSD PROJECT: GSD EEProcurement Project

AGENCY:AGENCY: GSD/SPD DATE:DATE: 2/17/09

PROJECT MANAGER:PROJECT MANAGER: Keith Campbell/Oracle, Inc. PROJECT #:PROJECT #:

ID:ID: DESCRIPTION:DESCRIPTION:OCCURRENCE OCCURRENCE DATE:DATE: OWNER:OWNER: SEVERITY:SEVERITY: COMMENTS:COMMENTS: STATUS:STATUS:

RESOLVED RESOLVED DATE:DATE:

129

AATTACHMENTTTACHMENT E: GSD M E: GSD MEMORANDUMEMORANDUM OFOF U UNDERSTANDINGNDERSTANDING FORFOR EEPPROCUREMENTROCUREMENT

130

AATTACHMENTTTACHMENT F: P F: PROJECTROJECT FORMSFORMS/T/TEMPLATESEMPLATES

Issue Report

Risk Report

Change Request

131

PPROJECTROJECT C CHANGEHANGE R REQUESTEQUESTProject:

AGENCY: DATE:

PROJECT MANAGER: PROJECT #:

AGENCY AND PROJECT INFORMATION:

REQUESTED BY: DATE:

AUTHORIZED BY: DATE:

DESCRIPTION:

IMPACT: Technical Schedule Cost Other

ACTION PLAN:

MARK ONE :THIS CHANGE: Is Is NOT Within Scope.

THIS CHANGE IS: Accepted Denied On Hold Delayed

PROJECT SPONSOR (BUSINESS OWNER) PROJECT MANAGER

132

SIGNATURE: SIGNATURE:

NAME: NAME:

DATE: DATE:

133

Project Management Office

IISSSSUUEE DDEESSCCRRIIPPTTIIOONN && RREESSOOLLUUTTIIOONN FFOORRMM ((TTOO BBEE UUSSEEDD WWIITTHH DDOOIITT RRIISSKK AANNDD IISSSSUUEESS LLOOGG TTEEMMPPLLAATTEE))

PPRROOJJEECCTT:: AGENCY:

PROJECT MANAGER:

ISSUE ID #: DATE: RAISED BY:

ISSUE PRIORITY: CRITICAL IMPORTANT NEEDS RESOLUTION

IISSSSUUEE DDEESSCCRRIIPPTTIIOONN::

AAPPPPRROOAACCHH//RREECCOOMMMMEENNDDAATTIIOONNSS::

FFUUNNCCTTIIOONNAALL AARREEAASS AAFFFFEECCTTEEDD::

IISSSSUUEE RREESSOOLLUUTTIIOONN DDIISSCCUUSSSSIIOONN -- PPAARRTTIIEESS IINNVVOOLLVVEEDD::

134

RRISKISK R REPORTEPORT (T(TOO BEBE USEDUSED WITHWITH D DOOIT RIT RISKISK ANDAND I ISSUESSSUES L LOGOG TTEMPLATEEMPLATE))

PROJECT: PROJECT:

SECTION I: INITIAL NOTIFICATION

REPORTED BY: REPORTED DATE:

DESCRIPTION:

PROBABILITY OF OCCURRENCE:

SEVERITY OF IMPACT ON PROJECT:

MITIGATION STRATEGY:

INITIAL CRITICALITY: (MARK ONE)

LOW RISK, GREEN MEDIUM RISK, YELLOW HIGH RISK, RED

SECTION II: STATUS TRACKING INFORMATION

NAME OF RISK: TRACKING ID:

RISK CLASSIFICATION: TARGET DATE:

ASSIGNED BUSINESS OWNER: ASSIGNMENT DATE:

CURRENT CRITICALITY: (MARK ONE)

LOW RISK, GREEN MEDIUM RISK, YELLOW HIGH RISK, RED

SECTION III: ANALYSIS

135

NAME OF RISK: TRACKING ID:

DETAILED SEVERITY OF IMPACT:

ESTIMATED DOLLAR VALUE OF IMPACT:

BASIS FOR ESTIMATED PROBABILITY:

ESTIMATED PROBABILITY OF OCCURRENCE:

MITIGATION STRATEGY:

CONTINGENCY PLAN:

SECTION IV: EVENT TRACKING

DESCRIPTION OF EVENT: DATE TAKEN: RESULTING DECISION:

INITIAL ANALYSIS COMPLETED:

FIRST PROJECT STATUS REPORT MADE:

UPDATE

UPDATE

CLOSED:

136

AATTACHMENTTTACHMENT G: P G: PROJECTROJECT B BUDGETUDGET

For a copy of the most current eProcurement Budget Report, contact John Prihoda, DFA Project Manager, [email protected]

137

mailto:[email protected]

AATTACHMENTTTACHMENT H: H: EEPPROCUREMENTROCUREMENT P PROJECTROJECT L LIBRARYIBRARY

The project library is an electronic storage place where all documentation relating to the project is stored and updated. This is a single source of project information for all stakeholders. The eProcurement Project Library includes Information:

Project Charter Project Management Plan Project Organization Structure Project Status Reports Meeting Agendas and Minutes Project Deliverable Artifacts and Documentation SPD Business and Functional Requirements eProcurement Project Certification Documents

138

AATTACHMENTTTACHMENT I: I: EEPPROCROC P PROJECTROJECT A ACRONYMSCRONYMS

CIO – Chief Information Officer

DFA – Department of Finance and Administration

DoIT – Department of Information Technology

ERP – Enterprise Resource Planning

ESC – Executive Steering Committee

GSD – General Services Department

GSD – General Services Department

IT – Information Technology

ITC – IT Commission, a State CIO sponsored commission

MAG – Multi Agency Team

PCC – Project Certification Committee

PD – Project director

PM – Project Manager

PMBOK – Project Management Book of Knowledge

PMI – Project Management Institute

RFP – Request for proposal

SPD – State Purchasing Division

WBS – Work breakdown structure

139

AATTACHMENTTTACHMENT J: P J: PROJECTROJECT M MANAGEMENTANAGEMENT D DEFINITIONSEFINITIONS

Below is a list of project management terms. These definitions were supplied by the NM Department of Information Technology office.

Acceptance Criteria

The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE-STD-610]

Acceptance Testing

Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. [IEE-STD-610]

Assumptions

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

Baseline

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

Commitment

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

Configuration Management (CM)

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

Configuration Management Library System

These are the tools and procedures needed to access the contents of the software baseline library.

Constraints

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

140

Contingency Planning

Contingency Planning is the development of a management plan that identifies alternative strategies to be used to ensure project success, if specified risk events occur.

Crashing

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

Critical Path

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

Dependencies, Discretionary

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

Dependencies, Mandatory

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

Dependency Item

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

Deliverable

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

Duration

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

Duration Compression

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

End User

141

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

Effort

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

Fast Tracking

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

Float

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

Formal Review

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

Integrated Project Plan

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

Lessons Learned

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

Method

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

Methodology

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

Milestone

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

Non-technical Requirements

142

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

Performance Reporting

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

Procurement Planning

Determining what to procure and when.

Product Scope

The features and functions that characterize a product or service.

Project Leader (Technical)

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

Project Management

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

Program

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

Program Management Office

An organizational entity responsible for management and oversight of the organization’s projects. As a specific reference in this document, the Office of the Chief Information Officer.

Project Manager

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

Project Charter

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

Project Management Plan

143

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

Project Schedule

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

Project Scope

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

Project Sponsor

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

Quality

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

The degree to which a system, component, or process meets customer or user needs or expectations. [IEEE-STD-610]

Quality Management

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

Risk

Possibility of suffering loss.

Risk Management

An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a more accurate understanding of, the risks involved. Risk Management includes risk identification, analysis, prioritization, and control. Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold.

Risk Management Plan

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

144

Scope Change

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

Software Life Cycle

The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The Software Life Cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation, and checkout phase, operation and maintenance phase, and, sometimes, retirement phase.

Stakeholder

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

145

AATTACHMENTTTACHMENT K: K: EEPPROCUREMENTROCUREMENT P PROJECTROJECT T TESTEST S STRATEGYTRATEGY

146

G GENERALENERAL S SERVICESERVICES D DEPARTMENTEPARTMENT EEPPROCUREMENTROCUREMENT P PROJECTROJECT

TTESTEST S STRATEGYTRATEGY

EXECUTIVE SPONSORARTURO JARAMILLO,

GENERAL SERVICES DEPARTMENT CABINET SECRETARY

BUSINESS OWNERROSS BOOM, SPD DEPUTY DIRECTOR

PROJECT MANAGERKEITH CAMPBELL, CONSULTANT, ORACLE, INC.

GSD CHIEF INFORMATION OFFICERKaren Baltzley

ORIGINAL EPROCUREMENT TEST STRATEGY DATE: AUGUST 6, 2009REVISION: 2.1

147



1.0 August 14, 2007 Original DoIT PMO Document

2.0 March 30, 2009 Original Draft for eProcurement Project Test Strategy

2.1 August 6, 2009 Update to test strategy

PAGE | 1

Table of ContentsREVISION HISTORY.........................................................................................................................................1

1 INTRODUCTION............................................................................................................................ 3

2 TEST OBJECTIVES.......................................................................................................................... 3

3 IDENTIFY TEST TYPES.................................................................................................................... 3

4 SCOPE OF TESTING........................................................................................................................ 4

5 TEST PREPARATION AND EXECUTION PROCESS.............................................................................5

5.1 Test Preparation.........................................................................................................................55.2 Test Execution.............................................................................................................................6

6 TEST DATA MANAGEMENT........................................................................................................... 7

7 TESTING ATTACHMENTS – PLANNING AND EXECUTION.................................................................8

PAGE | 2

11 INTRODUCTIONINTRODUCTION The Test Strategy documents the overall strategy for testing the processes and applications to be delivered by the project. The objectives of this document are:

Communicate the scope and phases of testing

Communicate the components that will be tested

Communicate the dependencies between testing phases and other projects

Communicate how the testing processes will be completed and managed

22 TEST OBJECTIVESTEST OBJECTIVESThe eProcurement Project testing intends to ensure that the future business processes, together with the SHARE (PeopleSoft) application, provides the expected business benefits. Testing objectives will include:

Validate that the applied optimizations perform as expected (that the right solution built and applied)

Ensure system components and business processes work end-to-end

May provide a test model that can be used on an ongoing basis

Identify and resolve issues and risks.]

33 IDENTIFY TEST TYPESIDENTIFY TEST TYPESThe eProcurement Project will conduct the following types of tests to verify that requirements have been met and to validate that the system performs satisfactorily.

Type of test Definition

Unit Testing Testing will be conducted to verify the implementation of the design for each optimization element (e.g., unit, module)

Integration Testing An orderly progression of testing in which software elements, hardware elements, or both are combined and tested until the entire system has been integrated

System Testing Formal testing will be conducted to determine that the functionalities resulting from the applied solutions satisfy the acceptance criteria and enables the SPD, DFA, and Agency customers to determine whether or not to accept the

PAGE | 3

Optimizations.

Regression / Integration Testing

Performed to confirm that the system changes can be successfully integrated with the existing functionality of the system.

Configuration Testing

During Development stage, Oracle will coordinate with SHARE to validate configuration modifications of the existing application over all the possible configurations on which it is supposed to run. During Development and Unit testing. Configuration validation will occur again during UAT and Regression/Integration testing.

Operational Readiness validation

After Optimization items have been moved to production, testers will use UPKs to determine any defects that will prevent deployment or functionality for the Purchasing users

Data migration and Load Testing

Oracle will coordinate with SHARE System Support to load some Commodity Codes and Vendor file data using .xls to Component Interface (CI) tool. QA testing for data integrity will occur during Development and Unit testing.

44 SCOPE OF TESTINGSCOPE OF TESTINGThe scope of eProcurement Optimization A testing will involve:

Testing both business processes and the technical solutions for (4)Purchasing, (4) Sourcing and (3) Contract related optimizations of the existing SHARE system (PeopleSoft) application.

Specifying regions and sub-regions included in testing

Identifying interfaces or interdependencies with other projects (including but not limited to procurement related aspects of DOT and SHARE ERP projects)

Identify interfaces with external entities such as dealers, suppliers, and joint ventures (eProcurement Project Optimizations will be built to enable State Purchasing Division to meet its requirements for Vendor Registrations and Invitations to Bid. The Procurement modules of the SHARE ERP system will allow access by outside vendors, Local Public Bodies. Visibility of these agreements must be made available to LPB’s. In addition, LPB’s require access to vendor preference data and LPB’s can utilize statewide pricing agreements.)

PAGE | 4

55 TEST PREPARATION AND EXECUTION PROCESSTEST PREPARATION AND EXECUTION PROCESS

5.15.1 TEST PREPARATIONTEST PREPARATIONeProcurement Project will prepare the following for testing of each of the Optimizations to be implemented. The eProcurement Test Preparation will verify that requirements are understood and prepare for Test Execution and will include these steps:

Identify test cases

Identify test cycles

Identify test data

Develop expected results

Develop test schedule (see Test Plan)

Obtain signoff

Optimization Item Test Cases

Test Cycles

Test Data Expected Results

Test Schedule

Sign Off

P2 – Configure 300 Commodity Codes

Complete Complete Complete Complete Complete Complete up to UAT and Regression Testing

S6/P6a – Configure Vendor Quote Groups


P10 – (no configuration changes or development) Re-engineer Business process and create UPK scripts that outline the use of the Distribution Line Item Entry


S1 – Configure Vendor Address and Location pages


S2 – Configure Complete Complete Complete Complete Complete Complete up to

PAGE | 5

functionality for “Duplicate Vendor” and “Inactivate Vendor” features

UAT and Regression Testing

S3 – Developed queries for DFA/FCD’s inactivation and/or conversion of Vendor files


C1a, C1b, C2 – (no configuration changes or development) Identify Business process and develop UPK scripts for Line Item processing and the recognition of Contract Pricing on a Requisition.


Note, User Acceptance Testing was completed as of 7/23/2009. Regression Testing was completed 9/23/2009 and a go-live meeting was held on

9/23/2009. Obtained approval for go-live from Tobi Andrade, Elena Tercero and Kathy Sanchez (meeting held September 23, 2009). Go-live will take place as scheduled on the week of October 9.

5.25.2 TEST EXECUTIONTEST EXECUTIONThe eProcurement Project will execute the test cycles and test cases created during the Test Preparation activity, compare actual results to expected results, and resolve any discrepancies. The eProcurement Project will follow the steps below for executing tests.

Verify entry criteria and updated UPKs

Conduct tests using updated UPKs and provided CRP Job Aides

Compare actual results to expected results

Investigate and resolve discrepancies

Conduct regression/integration tests

Verify exit criteria

Obtain signoff

PAGE | 6

66 TEST DATA MANAGEMENTTEST DATA MANAGEMENTThe eProcurement Project will use the following approach to identify and manage test data:

System and user acceptance tests – a subset of production data will be used to initialize the test environment. These tests will simulate the SHARE purchasing production environment and validate business transactions. eProcurement Project implementers (Oracle and Purchasing Business owners) will validate data integrity in the test environment to ensure that test results reliably simulate functionality of purchasing production.

Performance/volume/stress test – this project is changing business processes only. There will be no affect on system transaction volume or system performance.

Operational readiness validation – a copy of system/user acceptance test data could be used for the operational readiness test. Since the focus of the test is on operational procedures, a low number of transactions will be required and data integrity is not critical.

PAGE | 7

77 TESTING ATTACHMENTS – PLANNING AND EXECUTIONTESTING ATTACHMENTS – PLANNING AND EXECUTIONThe eProcurement Project utilized the plan (attached below as a PowerPoint) to execute User Acceptance Testing (UAT).

The eProcurement Project documented the following results. Original copies were retained by Oracle and copies were supplied to Susan Steinberg and John Prihoda.

The procurement team will utilize the following plan (attached below as a PowerPoint) to plan for Integration / Regression Testing.

PAGE | 8

[INSERT PROJECT NAME]€¦ · Web viewMarilyn Hill, Dep. Cab Sec. Pamelya Herndon, Dep. Cab. Sec....

Documents

Transcript of [INSERT PROJECT NAME]€¦ · Web viewMarilyn Hill, Dep. Cab Sec. Pamelya Herndon, Dep. Cab. Sec....