Project Management Plan1
NMDOT Forms Management Solution Project
PROJECT MANAGEMENT PLAN (PMP)
Executive Sponsor Tom Church, NMDOT Cabinet Secretary, DesignateBusiness Owner Bruce Oakeley, NMDOT ISM Bureau ChiefProject Manager Sal Hernandez, Integratus SolutionsOriginal Plan Date: December 13, 2013Revision Date: January 2, 2014Revision: 2.2
Revision History3
1.0 Project Overview4
1.2 funding and sources4
1.3 constraints5
1.4 dependencies5
1.5 ASSUMPTIONS6
1.6 Initial Project Risks Identified7
2.0 Project Authority and Organizational Structure8
2.1 Stakeholders8
2.2 Project Governance Structure9
2.2.1 Describe the organizational structure Org Chart9
2.2.2 Describe the role and members of the project steering committee9
2.2.3 Organizational Boundaries, interfaces and responsibilities9
2.3 Executive Reporting10
3.0 Scope10
3.1 Project Objectives10
3.1.1 Business Objectives10
3.1.2 Technical Objectives10
3.2 Project exclusions11
3.3 Critical Success Factors11
4.0 Project Deliverables and methodology12
4.1 Project Management Life Cycle12
4.1.1 Project Management Deliverables13
4.1.2 Deliverable Approval Authority Designations15
4.1.3 Deliverable Acceptance Procedure19
4.2 PRODUCT LIFE CYCLE19
4.2.1 Technical Strategy20
4.2.2 Product and Product Development Deliverables21
4.2.3 Deliverable Approval Authority Designations22
4.2.4 Deliverable Acceptance Procedure22
5.0 Project Work23
5.1 Work Breakdown Structure (WBS)23
5.2 Schedule allocation -Project Timeline24
5.3 Project Budget24
5.4 Project Team25
5.4.1 Project Team Structure, Roles and Responsibilities25
5.5 STAFF PLANNING AND Resource ACQUISITION26
5.5.1 Project Staff26
5.5.2 Non-Personnel resources26
5.6 PROJECT LOGISTICS26
5.6.1 Project Team Training27
6.0 Project Management and Controls27
6.1 Risk and issue Management27
6.1.1 Risk Management Strategy27
6.1.2 Project Risk Identification28
6.1.3 Project Risk Mitigation Approach28
6.1.4 Risk Reporting and Escalation Strategy28
6.1.5 Project Risk Tracking Approach29
6.1.6 ISSUE MANAGEMENT29
6.2 INDEPENDENT Verification And Validation - Iv&V29
6.3 Scope Management Plan30
6.3.1 Change Control30
6.5 Communication Plan31
6.5.1 Communication Matrix31
6.5.2 Status Meetings31
6.5.3 Project Status Reports31
6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS)32
6.7 QUALITY OBJECTIVES AND CONTROL32
6.7.1 quality Standards33
6.7.2 Project and Product Review AND ASSESSMENTS33
6.7.3 Agency/Customer Satisfaction34
6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS34
6.8 CONFIGURATION MANAGEMENT38
6.8.2 Project Repository (Project Library)38
7. 0 Project Close39
7.1 Administrative Close39
7.2 Contract Close39
Revision History
Revision Number
Date
Comment
1.0
July 27th, 2007
DoIT Project Management Plan template
2.0
December 30th, 2013
Initial creation of PMP from DoIT template
2.1
January 2nd, 2014
Revised to add rough scheduling and project task details
2.2
January 3, 2014
Revised to add Section 6 specifics and other content updates
2.3
1.0 Project Overview
The New Mexico Department of Transportation relies thoroughly on the forms catalog it presently has implemented within its agency. The information management practices around the usage of these documents are essential to the functioning of its business. There have been over three hundred forms identified as used for different areas within the agency.
These forms are currently created using an older methodology, which makes the information management practices cumbersome, manual-intensive and prone to human errors and delays. The manual process calls for forms to be printed and then delivered (via mail or fax) to the agency. The form submission process is decoupled from the process flow.
Furthermore, These forms reside on an aging system that requires it to be replaced before it begins to degrade service within the agency.
NMDOT has chosen to modernize and substantially improve the form submission process. Modernization Improvements will include digitizing the document submission process as well as improving the form submission lifecycle, this will reduce process times and errors. The intrinsic benefits include creating a more productive and responsive agency thereby increasing customer satisfaction.
1.2 funding and sources
Source
Amount
Associated restrictions
Approvers
NM State Road Fund
$500,000
1.3 constraints
The following factors can potentially restrict the project by scope, resource, or schedule.
Number
Description
1
Time Project will need to be closed out by June 30th 2014
2
Budget Project not to exceed $500K
3
Scope Project scope need not exceed existing project estimates and increased scope be addressed/approved or denied by Project Steering Committee
4
Software Project technical deliverables need to be developed with Adobe LiveCycle software and related tools
5
Resources - Project will need to be completed with a mix of NMDOT and Contractor resources
6
Budget Project cannot cause a dramatic shift in operational cost.
7
Process Project will adhere to applicable DoIT methodology
8
Agency Project will adhere to applicable NM State and NMDOT policies and regulations.
9
Agency Project technical deliverables to meet existing service agreements and response times.
10
Infrastructure Software must be configured and operate alongside existing NMDOT infrastructure without disrupting ongoing business service.
1.4 dependencies
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
Active Directory - ENSURE A PROPER MANAGEMENT INTERFACE EXISTS FOR THE ACTIVE DIRECTORY MANAGEMENT as well as ensure content is up to date
m, e
2
TRAINING - DELIVER PROPER DEVELOPMENT TRAINING for forms and portal developers
m
3
INSTALLATION AND CONFIGURATION - Ensure the proper hardware, software and infrastructure is made available
m, e
4
Organizational Buy-In - ENSURE executive and SME buy-in for new technology and process
M
5
Technological - ENSURE proper implementation of TBD approach (Electronic v digital signitures)
M
6
organizational - ENSURE Subject matter experts are excessible both functional and technical SMEs are required
m
1.5 ASSUMPTIONS
Number
Description
1
All system users exist in NMDOTs Active Directory. All system users are internal to the agency.
2
Business rules for form data and routing relating to existing forms are known and fixed.
3
Servers and client workstations meet or exceed the minimum requirements of the technology stack.
4
The form templates will be developed using a proper common format. If such a format is not possible, then the form will be provided in an alternative format and will be served as fill and print forms.
5
Project team will have access to functional and technical SMEs
1.6 Initial Project Risks Identified
[Risk 1 Active Directory]
Description Active Directory entries are incorrect thus effecting forms with workflow
Probability EXPECTED
Impact HIGH
Mitigation Strategy 2 fold strategy Initial and On-going
1. Initial There is an initial effort to clean up Active Directory entries in bulk, especially for those Users/Groups identified as prospects for forms with workflow.
2. On-going An interface will be developed for the Human Resources department to actively monitor and update Active Directory entries. Major Events (Hire to Fire) will trigger an resource to update the Active Directory.
Contingency Plan
1. Continuous efforts to clean up the Active Directory entries on a regular interval
[Risk 2 Software Features]
Description - Features and capabilities of the product may be wrong, incomplete, or too complex and that may not satisfy the requirement.
Probability LOW
Impact Medium
Mitigation Strategy
1. Complex scenarios were given to Vendor during a Proof of Concept initiative when evaluating software.
2. Additionally, ensure that all functionality is defined before development begins.
Contingency Plan
1. Co-Develop more difficult scenarios with Vendor or engage them for support as needed
2. Extend product, as needed with custom integration layers.
[Risk 3 Software Training]
Description Resource training on software is inadequate or has
