E€¦ · Web view21/11/2017 · • PMBOK • DoIT • MS Word • MS Excel • Testing Docs....

EMERGENCY GRANT MANAGEMENT PROGRAM (E-GraMP)

PROJECT MANAGEMENT PLAN (DRAFT)

Executive Sponsor – M. Jay Mitchell

Business Owners – Valli Wasp and Sarah Peterson

Project Manager – Duncan Sill

Original Plan Date: November 1, 2017

Revision Date: n/a

Revision No.: n/a

NM DHSEM ELECTRONIC GRANT MANAGEMENT PROGRAM(E-GraMP)

Table of ContentsRevision History 3

1.0 Project Overview 4

1.1 Executive Summary 4

1.2 Funding Sources 6

1.3 Constraints 7

1.4 Dependencies 7

1.5 Assumptions 8

1.6 Initial Project Risks Identified 8

2.0 Project Authority and Organizational Structure 9

2.1 Stakeholders 9

2.2 Project Governance Structure 9

2.2.1 Organization Chart 9

2.2.2 Project Steering Committee Members and Roles 10

2.2.3 Organizational Boundaries, Interfaces and Responsibilities 10

2.3 Executive Reporting 10

3.0 Scope 11

3.1 Project Objectives 11

3.1.1 Business Objectives 11

3.1.2 Technical Objectives 11

3.2 Project Exclusions 12

3.3 Critical Success Factors 12

4.0 Project Deliverables and Methodology 12

4.1 Project Management Life Cycle 12

4.1.1 Project Management Deliverables 13

4.1.2 Deliverable Approval Authority Designations 15

4.1.3 Deliverable Acceptance Procedure 15

4.2 Product Life Cycle 15

4.2.1 Technical Strategy 15

4.2.2 Product and Product Development Deliverables 15

4.2.3 Deliverable Approval Authority Designations 15

4.2.4 Deliverable Acceptance Procedure 15

2


5.0 Project Work 16

5.1 Work Breakdown Structure (WBS) 16

5.2 Schedule Allocation – Project Timeline 16

5.3 Project Budget 16

5.4 Project Team 16

5.4.1 Project Team Organizational Structure 16

5.4.2 Project Team Roles and Responsibilities 16

5.5 Staff Planning and Resource Acquisition 16

5.5.1 Project Staff 16

5.5.2 Non-Personnel Resources 16

5.6 Project Logistics 16

5.6.1 Project Team Training 16

6.0 Project Management and Controls 16

6.1 Risk and Issue Management 16

6.1.1 Risk Management Strategy 16

6.1.2 Project Risk Identification 16

6.1.3 Project Risk Mitigation Approach 16

6.1.4 Risk Reporting and Escalation Strategy 16

6.1.5 Project Risk Tracking Approach 16

6.1.6 Issue Management 16

6.2 Independent Verification and Validation (IV & V) 17

6.3 Scope Management Plan 17

6.3.1 Change Control 17

6.4 Project Budget Management 18

6.4.1 Budget Tracking 18

6.5 Communication Plan 18

6.5.1 Communication Matrix18

6.5.2 Status Meetings 18

6.5.3 Project Status Reports 18

6.6 Performance Measurement (Project Metrics) 18

6.6.1 Baselines 18

6.6.2 Metrics Library 18

3


6.7 Quality Objectives and Control 19

6.7.1 Quality Standards 19

6.7.2 Project and Product Review and Standards 20

6.7.3 Agency/Customer Satisfaction 20

6.7.4 Product Deliverable Acceptance Process 20

6.8 Configuration Management 21

6.8.1 Version Control 21

6.8.2 Project Repository (Project Library) 21

6.9 Procurement Management Plan 21

7.0 Project Close 21

7.1 Administrative Close 21

7.2 Contract Close 21

4


REVISION HISTORYRevision Number Date Comment Author

5


1.0 PROJECT OVERVIEW

1.1 EXECUTIVE SUMMARY

The New Mexico Department of Homeland Security and Emergency Management (NM DHSEM) heads the State’s response to emergencies and disasters while providing for the safety and welfare of its citizens. Emergencies and disasters can be defined as something caused by natural or human-made events or any other circumstances determined by the Governor and may be declared by the President of the United States. When necessary, the State assists local jurisdictions whose capabilities are overwhelmed, serving as a conduit for assistance from the Federal government.

The NM DHSEM, as the federal recipient, is the fiduciary agent over all federal funding passed through the agency and as such, is charged with grant oversight related to sub-recipients as well as the federal funding expended by NM DHSEM for its own programs and operations.

NM DHSEM acquires a majority of its grant funding from the US Department of Homeland Security’s (DHS) Federal Emergency Management Agency (FEMA). NM DHSEM is responsible for administering non-disaster grants, disaster grants, recurring grants and non-recurring grants. NM DHSEM supports 33 counties and 22 tribal governments, state agencies, sub-divisions of state government such as acequias and special districts, and certain private non-profits.

The Public Assistance program is authorized by the Robert T. Stafford Act, known simply as the Stafford Act, which provides grants to state, local, tribal governments, special districts and certain eligible non-profit entities to assist them after suffering a substantial loss due to a major disaster such as a fire, a flood, an earthquake, etc. The program assists the local government to achieve a somewhat “back to normal” status and in some cases, aids with hazard mitigation which protects the disaster area from future events from a similar disaster.

The Public Assistance (PA) Grant Management Program is a major grant program administered by the New Mexico Department of Homeland Security and Emergency Management. FEMA manages the program, approves the grants and provides technical assistance to the applicants.

The New Mexico Department of Homeland Security and Emergency Management assists FEMA with the PA Program and is responsible for implementing and monitoring the grant awards under this Program. NMDHSEM ensures that grantee and sub-recipient supported activities are in compliance with applicable federal requirements and that project goals are being achieved.

6


Local governments are responsible for identifying the damage, providing the required paperwork to FEMA to be able to approve the grants and manage the projects funded by the PA program.

As established under the Public Assistance Program by the Stafford Act, a grant is provided through a seventy five percent (75%) minimum federal share. The remaining twenty-five (25%) non-federal share is the responsibility of the State and/or applicant. The State of New Mexico has elected to pay ½ the non-federal share or 12.5%. When a disaster occurs and the local government seeks assistance, project worksheets are written either based on actual cost for work that is complete or they are based on estimates. Small projects are estimated and unless there is a significant over-run, then the estimate stands. FEMA does not adjust individual small project worksheets, they will address the over-run as a netting of all small projects. This is an appeal called Small Project Netting.

Large Projects are estimated, then upon completion, NM DHSEM inspects the site and performs a desk audit on the actual costs. If NM DHSEM, concurs with the costs, a letter is sent to FEMA requesting the Project total be adjusted (versioned) to match the actual cost.

When a disaster hits, either a portion of a community or multiple communities can be affected. The outcome of this is that NMDHSEM can have a range of 1 to 5000+ project worksheets to monitor and oversee for one disaster. This is for one grant program. NMDHSEM various disaster and non-disaster grant programs to oversee and these grant programs will be part of the RFP for procuring a web-hosted grant management software application.

The Department of Homeland Security and Emergency Management was created in 2007 merging the Governor’s Office Homeland Security and the Department of Public Safety’s Office of Emergency Management. The Department was obligated to learn each other’s existing policies and procedures and merge the processes while still undertaking the work of the various grant management programs that continued to come in for oversight. As a result, the NM DHSEM continues to work with an antiquated process, where everything is entered manually for every step and attempts to enhance their policies and procedures to provide improved customer service and efficiency.

Currently, NM DHSEM manages and administers its emergency management grant programs through manual processes which entail the use of Excel spreadsheets to track applicants, the project and funding from the project’s beginning to the project’s closeout.

The current processes are tedious, the amount of paperwork is cumbersome and is highly susceptible to error and yields itself to inadequate data and dross information. Because of so many variables in the funding and federal mandates from year to year

7


and the amount of project worksheets per disaster to monitor, the complex process can no longer be supported through the use of manual spreadsheets.

Additionally, NM DHSEM’s financial management systems, including records documenting compliance with federal and state statutes and regulations must be sufficient to permit the preparation of reports required on a regular basis.

To better manage all its non-disaster grants, disaster grants, recurring grants and non-recurring grants administered, NM DHSEM will be pursuing a RFP to contract with a vendor who can meet its specifications of a web-hosted software program. This program should have the ability to monitor grants throughout the entire grant management process for all grant programs, provide customized and ad-hoc reporting and enhance collaboration and communication with local entities and FEMA.

Because the Public Assistance program is a major grant program for NM DHSEM and is often the program much under scrutiny and negative audit findings, this program will have priority over other grants for implementation. This means that all the Emergency Grant programs will be part of the RFP, but this program will be first to implement. Because of this intention, there may be a Phase 2 added in order to satisfy this need.

The goals of procuring a web-hosted emergency grant management software program:

To track applicants, grants, projects, funding and to have the ability to produce ad-hoc as well as on-line customized reports.

To increase efficiency through improved collaboration and communication requirements for both state, local and federal entities.

To assist the agency and the applicants to monitor milestones and meet deadlines.

To improve productivity and efficiency. To drastically reduce the processing time to disburse funds. To improve reporting requirements to state, local and FEMA. To streamline business processes and improve internal controls. To reduce deficiencies in audit findings by reducing errors through development

of consistent work processes and procedures and the establishment of an audit trail of work flows.

1.2 FUNDING SOURCE(S)

SOURCE AMOUNT ASSOCIATED RESTRICTIONS

Federal Funding – Disaster Management Costs $960,000.00 None

8


1.3 CONSTRAINTS

NUMBER DESCRIPTION1 Scope change of direction either

management mandated or through FEMA regulation changes.

2 Federal funding decreased due to US budget shortfalls; unable cover all grant programs to be implemented.

3 Federal database changes and will not interface as planned with our system requiring more IT changes.

4 Resources are limited due to existing workloads or leaving the Agency.

5 Because of the various issues that negatively have affected NMDHSEM, a mandate to complete project in less time is implemented.

1.4 DEPENDENCIES

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.

NUMBER DESCRIPTION TYPE M, D, E

1 Project Certification Committee approval. M

2 RFP approval, posting and vendor selection. M

9


1.5 ASSUMPTIONS

NUMBER DESCRIPTION1 Staff resources will be fully available, as requested, to assist with the

various project phases.2 Decisions on particular issues requiring approval will be made timely.3 All business requirements were properly documented and ready to be

implemented for a successful project.4 Funding will be available throughout the duration of this project.5 Consulting staff will not be limited and will be fully available to serve NM

DHSEM project needs.

1.6 INITIAL PROJECT RISKS IDENTIFIED

RISK 1: ORGANIZATIONAL READINESS WHERE THE AGENCY MAY WANT TO PROGRESS WITH THE PROJECT TOO QUICKLY WITH LACK OF PROPER PLANNNING.

PROBABILITY: MEDIUM

IMPACT: Program is not as functional as expected to perform daily tasks.

MITIGATION STRATEGY: Extend planning timeline.

CONTINGENCY PLAN: Extend planning timeline.

RISK 2: INADEQUATE MANAGEMENT COMMITMENT OF RESOURCES TO PARTICIPATE IN PROJECT AS ASSIGNED RESOURCES CONTINUE TO HAVE NORMAL, DAILY RESPONSIBILITIES.

PROBABILITY: MEDIUM

IMPACT: Project doesn’t meet goals due to lack of resources.

MITIGATION STRATEGY: Hire augment staff prior to project start date to train on duties to undertake during the project.

CONTINGENCY PLAN: Train augment staff prior to performING their job duties. Subject matter experts to support project.

RISK 3: NOT FINDING A QUALIFIED VENDOR WITH A COMMERCIAL OFF-THE-SHELF WEB-HOSTED SOFTWARE PROGRAM THAT MEET THE REQUIREMENTS OF THE AGENCY.

PROBABILITY: LOW

10


IMPACT: Continue to operate with manual processes.

MITIGATION STRATEGY: Continue to operate with manual processes.

CONTINGENCY PLAN: Review where vendor is lacking in qualifications or revise scope of work and business requirements.

RISK 4: CHANGES WITH THE FEMA PROGRAM THAT COULD IMPACT AGENCY REQUIREMENTS ONCE PROJECT IN IMPLEMENTATION PHASE.

PROBABILITY: LOW

IMPACT: Dependent on FEMA changes, Offeror may need to adjust scope of work to customize certain portions within their COTS software to be migrated into the work product to be implemented for the NM DHSEM. There may be possible impact to schedule and budget impacts.

MITIGATION STRATEGY: Project Manager to maintain proactive communications with FEMA personnel relating to possible upcoming emergency grant management changes through laws and/or procedures to be able to adjust scope of work or work with Offeror, if necessary.

CONTINGENCY PLAN: Work with Offeror regarding keeping schedule on track or as close to on track if at all possible. The system being procured has the ability to absorb updates.

RISK 5: OFFEROR SET TO PROVIDE A NEW RELEASE OF THEIR EMERGENCY GRANT SOFTWARE PROGRAM AT IMPLEMENTATION PHASE.

PROBABILITY: LOW

IMPACT: Dependent on new release, new configurations and planning/implementation documents may need to be adjusted. This may cause schedule to slip or new requirements to be implemented.

MITIGATION STRATEGY: Project Manager to maintain proactive communications with the successful offeror for potential new release(s) of software that may be implemented in the near future and determine a new strategy should project schedule be impacted or scope of work continues.

CONTINGENCY PLAN: Work with Offeror regarding schedule and implementation impacts. Adjust documents accordingly.

RISK 6: USER RESISTANT TO CHANGE/BUY-IN

11


PROBABILITY: MEDIUM

IMPACT: Project becomes slow to implement as participants do not want to provide input. Also, project can become useless once installed if procedures are not being followed and “old processes” are followed.

MITIGATION STRATEGY: : Executive sponsor and project manager to host a kick-off meeting/presentation at start of planning phase to introduce the contract awarded vendor and address the commitment to this project and what this project will ultimately do for the agency. Advise participants of the importance to react when information is requested or participate as scheduled. Also, communicate with participants what will take place during the implementation phase, monitor and controlling phase and closeout phase.

CONTINGENCY PLAN:RISK 7: LACK OF UNDERSTANDING OF AGENCY REQUIREMENTS BY THE OFFEROR

PROBABILITY: LOW

IMPACT: Potential schedule fallback in order to inform and train Offeror of agency requirements.

MITIGATION STRATEGY: Review system requirements upfront with the Offeror so that items are fully understood.

CONTINGENCY PLAN: Project manager to closely monitor validation reviews, work break down structures, testing, etc. to ensure agency requirements, scope, schedule and budget are being met. Project manager will work with vendor to prioritize work and/or to re-direct project teams when necessary.

RISK 8: DATA REQUIREMENTS OF THE AGENCY ARE INCONSISTENT OR NOT AVAILABLE WITH THOSE OF THE SOFTWARE REQUIREMENTS.

PROBABILITY: LOW

IMPACT: Potential schedule adjustment and scope of work adjustment.

MITIGATION STRATEGY: Identify data requirements upfront to determine how the data can be located and added to the script to support business objectives.

CONTINGENCY PLAN: Determine if the Agency can better adapt to Offeror software requirementsRISK 9: DATA IS NOT BACKED UP OFTEN WHICH COULD DELAY THE PROJECT IN ORDER TO RECONSTRUCT THE DATA.

12


PROBABILITY: LOW

IMPACT: Loss of work performed and potential schedule adjustment to have data re-entered.

MITIGATION STRATEGY: Set backup mandates and checklist of daily functions to be followed.

CONTINGENCY PLAN: Set backup mandates and at end of day review work progress.RISK 10: DECISION DELAYS IMPACT PROJECT

PROBABILITY: LOW

IMPACT: Possibility of schedule fallback by the number of days it takes to make decision(s).

MITIGATION STRATEGY: Establish decision guideline turnaround time and direct communication of designee’s schedule.

CONTINGENCY PLAN: Determine an alternate person who has the ability to make the necessary decisions in the event of main designee unavailable.

RISK 11: IT ARCHITECTURE PLAN DOES NOT ALIGN WITH DOIT POLICIES AND STANDARDS.

PROBABILITY: LOW

IMPACT: Schedule delays and possible contract concerns if Offeror advised that would be in alignment with DOIT policies as what was addressed in the RFP procurement document.

MITIGATION STRATEGY: Project Manager to review DoIT policies and procedures and ensure software can meet the infrastructure.

CONTINGENCY PLAN: Determine those items in which IT Architecture Plan does not align with DOIT policies and standards to establish potential impact on schedule and Offeror being unable to perform job requirements.

RISK 12: RESPONSE TIME OF SYSTEM IS NOT ACCEPTABLE TO USERS.

PROBABILITY: LOW

IMPACT: Unhappy users who have to wait on the system to respond to action requested which can push the users to not utilize the system and follow past practices. Potential

13


delay in schedule to make adjustments as necessary to software.

MITIGATION STRATEGY: The system should be designed to the maximum numbers of end users.

CONTINGENCY PLAN: Potential re-designing of certain system requirements to make adjustments to software to increase response time of system.

RISK 13: TIMELINES EXTENDED DUE TO OTHER STATE AGENCIES WHO REQUIRE OVERSIGHT APPROVALS OF THE PROJECT.

PROBABILITY: MEDIUMIMPACT: Schedule delays in project.

MITIGATION STRATEGY: Add additional time to those portions of the timelines where other state agency approvals are required.

CONTINGENCY PLAN: Add additional time to those portions of the timelines where other state agency approvals are required.

RISK 14: EMPLOYEES ASSIGNED TO THE PROJECT IMPACTED BY MANDATORY TRAINING OR DEPLOYMENT OF EMERGENCIES.

PROBABILITY: MEDIUM

IMPACT: Delay in project implementation and operations because resources are unavailable to work on project.

MITIGATION STRATEGY: Executive management to determine the priorities of the mandatory training and project participation for the employees and their managers.

CONTINGENCY PLAN: Work closely with training staff schedules for those individuals who would be working on project during certain time frames.

14


2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE

2.1 STAKEHOLDERS

NAME STAKE IN PROJECT

ORGANIZATION TITLE

M. Jay Mitchell Cabinet Secretary NM DHSEM Cabinet SecretarySarah Peterson Business Owner NM DHSEM ASD Bureau ChiefValli Wasp Business Owner NM DHSEM Recovery and

Response Bureau Chief

Mark Rivera Systems Support NM DHSEM IT ManagerInternal Users Internal Users Various VariousFEMA Project Oversight US DHS Federal GovernmentVarious Local and Tribal Entities

Supports 33 Counties and 22 Tribal Governments

Various

2.2 PROJECT GOVERNANCE STRUCTURE

2.2.1 PROJECT ORGANIZATIONAL STRUCTURE

M. Jay MitchellCabinet Secretary

David CeballesDeputy Secretary

Sarah PetersonAdmin Svc Bureau

Susan WalkerPreparedness

Bureau

Valli WaspResponse &

Recovery Bureau

VacantIntelligence & Security

Bureau and Fusion Center

Johanna KehoeFinancial Svc Unit

Marcella BentonLocal Preparedness

Unit

Wynn BranninEmergency

Communication Unit

Vincent SalazarCritical Infrastructure Unit

Craig BaconGeneral Svc Unit

Wendy BlackwellHazard Mitigation

Unit

VacantEmergency

Operations UnitVacant

NMASIC Unit

Duncan SillGrant Mgmt Unit

and Project Manager for E-

GrampTo Be DeterminedIV & V Contractor

Joyce PurleyTrng & Exercise Unit

Brian WilliamsRecovery Unit

Mark RiveraInfo Tech Unit

NM DEPARTMENT OF HOMELAND SECURITY AND EMERGENCY MANAGEMENT

15


2.2.2 PROJECT STEERING COMMITTEE ROLES, MEMBERS AND RESPONSIBILITIES

ROLE RESPONSIBILITYExecutive Project Sponsor

The highest level of the NM DHSEM and for this project.Responsibilities include:

Has final authority of NM DHSEM and the project. Approves changes to the project. Communicates the project priorities and expectations to

team members and stakeholders. Assigns the necessary resources to ensure participation

for the success of the project. Ensures that project resources are available and if not,

considers alternate resources in order not to stall the project.

Monitors project progress by communicating with Project Manager and Project Team Leads.

Signs off on the project close-out.Steering Committee Member or Project Manager

16


3.0 SCOPE

3.1 PROJECT OBJECTIVES

3.1.1 BUSINESS OBJECTIVES

NUMBER DESCRIPTIONBusiness Objective 1 To track applicants, grants, projects,

funding.Business Objective 2 To increase efficiency through improved

collaboration and communication requirements for state, local and federal entities.

Business Objective 3 To assist the agency and applicants to monitor milestones and meet deadlines.

Business Objective 4 To improve productivity and efficiency.Business Objective 5 To drastically reduce the processing time

to disburse funds.Business Objective 6 To improve reporting requirements to

state, local and FEMA.Business Objective 7 To streamline business processes and

improve internal controls.Business Objective 8 To reduce deficiencies in audit findings by

reducing errors through development of consistent work processes and procedures and the establishment of an audit trail of work flows.

3.1.2 Technical Objectives

NUMBER DESCRIPTIONTechnical Objective 1 NM DHSEM is writing an RFP for a web-

hosted, commercial, off-the-shelf software application that requires minimal customization. Technical objectives will be added as the Initiation process continues.

3.2 PROJECT EXCLUSIONS

17


3.3 CRITICAL SUCCESS FACTORS

Identify the critical success factors for achieving success in this project. Metrics 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 schedules and budget.

NUMBER DESCRIPTIONQuality Metrics 1 The project scope, schedule, budget,

milestones and deliverables are met.Quality Metrics 2 The staff is properly trained and able to

utilize the system to perform job tasks.Quality Metrics 3 The reporting systems can accurately track

data and integrate monthly, weekly and ad-hoc reports.

Quality Metrics 4 The system is secure and able to provide an audit trail of functions performed.

Quality Metrics 5 Real time data will improve trust and customer relations.

4.0 PROJECT DELIVERABLES AND METHODOLOGY

4.1 PROJECT MANAGEMENT LIFE CYCLE

Phase Summary of Phase Key DeliverablesPlanning Project Plan

Resource Allocations Scope, Schedule, Budget

Project Design Required Documents Workflow Design

System and Acceptance Testing

Test Plan Test Scripts Tracking Logs

Training Training Materials Training Class

Implementation Implementation Schedule Tracking Logs

Support/Closing Transition Plan Close-Out Report Support Plan

18


4.1.1 PROJECT MANAGEMENT DELIVERABLES

*Once a vendor is selected, the product deliverables will be revised. Need to get RFP info here.

4.1.1.1Project 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.

4.1.1.2Certification 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.

4.1.1.3Project 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.”

4.1.1.4IV & 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

19


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.

4.1.1.5IT Service Contracts The Department of Information

Technology and the State Purchasing Divisions of General Services have established a template for all IT related contracts.

4.1.1.6Risk 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.

4.1.1.7Project Schedule A tool used to indicate the planned dates,

dependencies and assigned resources for performing activities and for meeting milestones. The defacto standard is Microsoft Project.

4.1.1.8Monthly 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.

4.1.1.9

20


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.

4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS

4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE

4.2 PRODUCT LIFE CYCLE

PHASE SUMMARY OF PHASE KEY DELIVERABLES

4.2.1 TECHNICAL STRATEGY

4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES

4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS

DELIVERABLE NO. DELIVERABLE APPROVERS (WHO CAN APPROVE)

DATE APPROVED

4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE

The Project Manager shall present the deliverables along with a recommendation for approval to the Executive Steering Committee during a regularly scheduled steering committee meeting. The Executive Steering Committee must then vote to accept or reject the deliverable with the vote reflecting a majority decision.

If the deliverable is rejected, the Project Manager will inform the vendor of the Executive Steering Committee’s action. The Project Manager shall describe, in writing, why the deliverable was rejected and what actions must

21


be addressed by the vendor prior to the deliverable being presented to the Executive Steering Committee, again.

5.0 PROJECT WORK

5.1 WORK BREAKDOWN STRUCTURE (WBS)

5.2 SCHEDULE ALLOCATION – PROJECT TIMELINE

5.3 PROJECT BUDGET

5.4 PROJECT TEAM5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES

5.5 STAFF PLANNING AND RESOURCE ACQUISITION

5.5.1 PROJECT STAFF5.2.2 NON-PERSONNEL RESOURCES

5.6 PROJECT LOGISTICS5.6.1 PROJECT TEAM TRAINING

6.0 PROJECT MANAGEMENT AND CONTROLS

6.1 RISK AND ISSUE MANAGEMENT6.1.1 RISK MANAGEMENT STRATEGY6.1.2 PROJECT RISK IDENTIFICATION6.1.3 PROJECT RISK MITIGATION APPROACH6.1.4 RISK REPORTING AND ESCALATION STRATEGY6.1.5 PROJECT RISK TRACKING APPROACH6.1.6 ISSUE MANAGEMENT

6.1.6.1 INTERNAL ISSUE ESCALATION AND RESOLUTION PROCESS6.1.6.2 EXTERNAL ISSUE ESCALATION AND RESOLUTION PROCESS

6.2 INDEPENDENT VERIFICATION AND VALIDATION – IV&V

6.3 SCOPE MANAGEMENT PLAN

22


6.3.1 CHANGE CONTROL

6.3.1.1 CHANGE CONTROL PROCESS

The key component to a successful project is being able to control project changes that have the potential of impacting the scope, schedule and budget. The Planning Phase is of great importance. The Planning phase needs to be well thought out. Project team members must understand their current workflow and the suggested workflow to be driven by the technological solution. Successful planning can avoid excessive scope changes related to business requirements and specifications.

During the planning stages, the Project Team should establish the baseline product and obtain agreement amongst the project team prior to moving forward.

Changes can be expected; therefore, a change control process is vital and will be implemented. A formal process has been established and is to be followed to ensure all changes are well documented, reviewed, approved or disapproved. throughout the change control process, a change request for has been created to do this.

6.3.1.2 CHANGE CONTROL BOARD (CCB)

Change requests submitted will be evaluated by the change control board that has been established:

Name Title Project RoleSarah Peterson Business OwnerSusan Walker Project Team MemberDuncan Sill Project ManagerDavid Ceballes Project Team MemberMark Rivera Steering CommitteeValli Wasp Steering Committee

This group will take into consideration the change request that impact scope, schedule and budget, justifications and befits and the impact.

The Change Control Board will meet weekly to review the change request and make a recommendation on the resolution of the change requests. The change board group must have a unanimous vote for the outcomes, make a recommendation of the outcome to accept, deny or placed on hold.

23


If change requests cannot be resolved unanimously by the Change Control Board, the change request will be escalated to the Executive Sponsor level for evaluation and resolution.

A synopsis of why the group could not reach a decision, alongside the change request) will be provided to the Executive sponsors to help understand the reasoning behind the Change Control Board members.

6.4 PROJECT BUDGET MANAGEMENT6.4.1 BUDGET TRACKING

6.5 COMMUNICATION PLAN6.5.1 COMMUNICATION MATRIX6.5.2 STATUS MEETINGS6.5.3 PROJECT STATUS REPORTS

6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)

The Project Manager and Executive Sponsor define the project metrics that will be used to control the project. Metrics are collected for measuring the progress of a project against its planned budget, schedule, resource usage, error rates and of establishing a historical data base, which will aid in planning and forecasting future projects.

6.6.1 BASELINES

Project Area Category MeasureScope Scope Adherence >3 Change RequestsSchedule Project On Time or AheadBudget Budget Under

6.6.2 METRICS LIBRARY

6.7 QUALITY OBJECTIVES AND CONTROL

Quality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, quality assurance, quality control and quality improvement within the quality system.

24


Not only is it important to complete the project on time, within scope and within budget, it is also important that the program accepted works as designed and functional to end users.

6.7.1 QUALITY STANDARDS

These quality standards will be used to assess whether the quality objectives were achieved.

No. Quality Standards1 An IV & V vendor will be available during the implementation phase of

the project to provide a third-party review and evaluation of the project and offer recommendations.

2 There are various Information Technology standards by DoIT that must be adhered to throughout project lifecycle.

3 There is a Change Control Board in place so when a change request comes to them, it will be reviewed for impact to scope, schedule, budget and quality prior to being approved.

4 Project reviews that show the progress and the deliverables specified in the contract and project schedule are met.

6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTS

Review Type Quality Standard

Tools Reviewer Reports

Requirements • NM Statutes• FEMA Statutes• DoIT• Work Flows

• MS Excel• MS Word• Product

• Steering Committee

PlansMilestones • PMBOK • Schedule • Steering

Committee• Status Reports

Testing • PMBOK• DoIT

• MS Word• MS Excel• Testing Docs.

• Project Mgr.• Test Team

• Test Strategy• Use Cases• Test Results

6.7.3 AGENCY/CUSTOMER SATISFACTION

25


The Project Manager will assess agency/customer satisfaction on an on-going basis through various means. This feedback will be helpful to the success of the project and the professional growth of the project team members.

Areas of Feedback When How OftenAgency Awareness • Project Status Reports

• NM DHSEM Unit Meetings• Monthly•?

Quality of Communication • Website of Project ?• Various Meetings

• Weekly• Various

Manages Project Tasks • Project Meetings• Project Status Reports

• Weekly• Weekly

Productive Meetings •Project Status Meetings • Monthly

6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS

The NM DHSEM Project Manager will take delivery of media, manuals, contracts, licenses, service 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 after acceptance by the Executive Steering Committee.

6.8 CONFIGURATION MANAGEMENT6.8.1 VERSION CONTROL

6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY)

SharePoint will be implemented for NM DHSEM to track project documentation.

6.9 PROCUREMENT MANAGEMENT PLAN

All procurement for this project is being conducted in accordance to NMSA 1978 Chapter 13 Procurement Statutes and is working under the guidance of State Purchasing Division’s established policies and procedures and DoIT guidelines.

7.0 PROJECT CLOSE

Project 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.

26


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 ADMINISTRATIVE CLOSE7.2 CONTRACT CLOSE7.3 LESSONS LEARNED7.4 PCC PRESENTATION FOR CLOSE-OUT

27

E€¦ · Web view21/11/2017 · • PMBOK • DoIT • MS Word • MS Excel • Testing Docs....

Documents

Transcript of E€¦ · Web view21/11/2017 · • PMBOK • DoIT • MS Word • MS Excel • Testing Docs....