Embed Size (px)
Citation preview
RLD ACCELA REPLACEMENT PROJECT
PROJECT MANAGEMENT PLAN (PMP)
EXECUTIVE SPONSOR – ROBERT UNTHANK, SUPERINTENDENT, RLDRLD BUSINESS OWNER – ROBERT UNTHANK, SUPERINTENDENT, RLDMHD BUSINESS OWNER – JESUS CARRASCO, MHD BUREAU CHIEF, RLDLPG BUSINESS OWNER – CLAY BAILEY, LPG BUREAU CHIEF, RLDCMS BUSINESS OWNER – AMANDA ROYBAL, CMS BUREAU CHIEF, RLDPRM BUSINESS OWNER – RICHARD LUCERO, PRM BUREAU CHIEF, RLDAGENCY CIO/IT LEAD – MICHELLE LANGEHENNIG, CHIEF INFORMATION OFFICER, RLDPROJECT MANAGER – FABIO MIR, APPLICATIONS DEVELOPER, RLDORIGINAL PLAN DATE: MAY 23, 2018REVISION DATE: JUNE 5, 2018
REVISION: 1.1
REVISION HISTORY.............................................................................................................................................. 3
1.0 PROJECT OVERVIEW...................................................................................................................................... 4
1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT................................................................................................41.2 FUNDING AND SOURCES...........................................................................................................................................41.3 CONSTRAINTS........................................................................................................................................................51.4 DEPENDENCIES.......................................................................................................................................................51.5 ASSUMPTIONS...................................................................................................................................................51.6 INITIAL PROJECT RISKS IDENTIFIED...........................................................................................................................9
1.6.1 External Risks............................................................................................................................................91.6.2 Internal Risks...........................................................................................................................................11
2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE...........................................................................12
2.1 STAKEHOLDERS....................................................................................................................................................122.2 PROJECT GOVERNANCE STRUCTURE.........................................................................................................................12
2.2.1 Describe the organizational structure – Org Chart..................................................................................132.2.2 Describe the role and members of the project steering committee.........................................................132.2.3 Organizational Boundaries, interfaces and responsibilities.....................................................................13
2.3 EXECUTIVE REPORTING..........................................................................................................................................14
3.0 SCOPE......................................................................................................................................................... 14
3.1 PROJECT OBJECTIVES............................................................................................................................................143.1.1 Business Objectives.................................................................................................................................143.1.2 Technical Objectives................................................................................................................................14
3.2 PROJECT EXCLUSIONS............................................................................................................................................153.3 CRITICAL SUCCESS FACTORS...................................................................................................................................15
4.0 PROJECT DELIVERABLES AND METHODOLOGY.............................................................................................16
4.1 PROJECT MANAGEMENT LIFE CYCLE........................................................................................................................164.1.1 Project Management Deliverables..........................................................................................................164.1.2 Deliverable Approval Authority Designations..........................................................................................174.1.3 Deliverable Acceptance Procedure..........................................................................................................17
4.2 PRODUCT LIFE CYCLE.......................................................................................................................................174.2.1 Technical Strategy...................................................................................................................................184.2.2 Product and Product Development Deliverables.....................................................................................184.2.3 Deliverable Approval Authority Designations..........................................................................................194.2.4 Deliverable Acceptance Procedure..........................................................................................................19
5.0 PROJECT WORK........................................................................................................................................... 19
5.1 WORK BREAKDOWN STRUCTURE (WBS)..................................................................................................................195.2 SCHEDULE ALLOCATION -PROJECT TIMELINE..............................................................................................................205.3 PROJECT BUDGET.................................................................................................................................................205.4 PROJECT TEAM....................................................................................................................................................21
5.4.1 Project Team Organizational Structure...................................................................................................215.4.2 Project Team Roles and Responsibilities..................................................................................................21
5.5 STAFF PLANNING AND RESOURCE ACQUISITION................................................................................................225.5.1 Project Staff.............................................................................................................................................235.5.2 Non-Personnel resources.........................................................................................................................23
5.6 PROJECT LOGISTICS.........................................................................................................................................235.6.1 Project Team Training.............................................................................................................................23
6.0 PROJECT MANAGEMENT AND CONTROLS....................................................................................................23
PAGE | 1
6.1 RISK AND ISSUE MANAGEMENT..............................................................................................................................236.1.1 Risk Management Strategy.....................................................................................................................236.1.2 Project Risk Identification........................................................................................................................246.1.3 Project Risk Mitigation Approach............................................................................................................246.1.4 Risk Reporting and Escalation Strategy...................................................................................................246.1.5 Project Risk Tracking Approach...............................................................................................................246.1.6 ISSUE MANAGEMENT..............................................................................................................................25
6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&V...........................................................................................266.3 SCOPE MANAGEMENT PLAN..................................................................................................................................26
6.3.1 Change Control........................................................................................................................................276.4 PROJECT BUDGET MANAGEMENT............................................................................................................................28
6.4.1 Budget Tracking......................................................................................................................................286.5 COMMUNICATION PLAN........................................................................................................................................29
6.5.1 Communication Matrix............................................................................................................................296.5.2 Status Meetings.......................................................................................................................................306.5.3 Project Status Reports.............................................................................................................................30
6.6 PERFORMANCE MEASUREMENT (PROJECT METRICS).....................................................................................306.6.1 Baselines.................................................................................................................................................306.6.2 Metrics Library........................................................................................................................................31
6.7 QUALITY OBJECTIVES AND CONTROL..............................................................................................................316.7.1 quality Standards....................................................................................................................................316.7.2 Project and Product Review AND ASSESSMENTS.....................................................................................326.7.3 Agency/Customer Satisfaction................................................................................................................326.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS......................................................................................32
6.8 CONFIGURATION MANAGEMENT...................................................................................................................336.8.1 Version Control........................................................................................................................................346.8.2 Project Repository (Project Library).........................................................................................................34
6.9 PROCUREMENT MANAGEMENT PLAN............................................................................................................34
7. 0 PROJECT CLOSE........................................................................................................................................... 35
7.1 Administrative Close...................................................................................................................................357.2 Contract Close............................................................................................................................................36
ATTACHMENTS................................................................................................................................................. 36
PAGE | 2
REVISION HISTORY
REVISION NUMBER DATE COMMENT
1.0 May 23, 2018 Draft
1.1 June 5, 2018 Submitted for Review
PAGE | 3
1.0 PROJECT OVERVIEW
1.1 EXECUTIVE SUMMARY- RATIONALE FOR THE PROJECT The State of New Mexico Regulation and Licensing Department (RLD) - Construction Industries Division (CID) and Manufactured Housing Division (MHD) - seeks to replace its current permitting and inspection software, Accela.
The purpose of the CID is to promote the general welfare of the people of New Mexico by providing for the protection of life and property by adopting and enforcing codes and standards for construction, alteration, installation, connection, demolition and repair work. The purpose of the MHD is to insure the purchasers and users of manufactured homes the essential conditions of health and safety which are their right and to provide that the business practices of the industry are fair and orderly among the members of the industry with due regard to the ultimate consumers in this important area of human shelter.
The Accela suite (Citizen Portal, Automation, and Mobile Inspection) supports the functionality of all permitting related to Construction Industries, Manufactured Housing, LP Gas and field inspections. CID permitting collects an estimated $4,000,000 in revenue for New Mexico’s State General Fund.
The current Accela system poses continual problems for both CID staff and the Information Technology Division. Mobile Inspection, used by field staff, loses its settings and has to be reinstalled nearly 50% of the time and it recently experienced a two-month outage. The Accela suite, is not PCI compliant. After June 30, 2018, Accela will no longer support the current installation requiring that customers purchase their new cloud-based version. RLD legal team took action, requesting reimbursement of $700,000.
RLD obtained three price quotes for a customized permitting and inspection software solution from companies on state price agreement and found Salesforce implemented by ANM to be the best option.
1.2 FUNDING AND SOURCES
SOURCE AMOUNT ASSOCIATED RESTRICTIONS
APPROVERS
Laws of 2019, Chapter 73, Section 7 (16)
$967,000 NONE LEGISLATION
GOVERNOR
1.3 CONSTRAINTS
PAGE | 4
NUMBER DESCRIPTION
1 Funding
2 Staff time
3 Unforeseen obstacles
1.4 DEPENDENCIESTypes include the following and should be associated with each dependency listed.
Mandatory dependencies are dependencies that are inherent to the work being done. D- Discretionary dependencies are dependencies defined by the project management team. This may also
encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.
E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement
NUMBER
DESCRIPTION TYPE M,D,E
1 EXISTING PERMIT DATA MUST MIGRATE M
2 PRE-PAID ACCOUNTS MUST MIGRATE M
3 INSPECTORS MUST HAVE ANDROID OR IPHONE D
4 CONTRACT APPROVALS E
1.5 ASSUMPTIONS
NUMBER DESCRIPTION
1 ANM stays in business and remains on statewide price agreements
2 RLD IT team is regularly available for technical discussions and project management
3 Project will be completed within defined timeline
4 Project scope will not change
5 Information in the Accela System will be available in a SQL Database that can be accessed and queried by ANM. During the Design Phase, ANM and RLD will determine if all data from Accela must be migrated to Salesforce
PAGE | 5
NUMBER DESCRIPTION
or if a hybrid approach where some Data is Migrated and some Data is Implemented is possible.
6 ANM will perform data migration from Accela, no files migration. RLD will perform any required file migrations (for documents related to Permits that may be stored in a separate file storage location). This may require the RLD team to manually migrate the files from Accela to the Document Management Solution.
RLD will have a window period of at least 1 week where no pre-paid account data will be entered or modified in the Accela System while the information is migrated to the new platform.
Salesforce provides 2 different mobile applications that can be used with this solution: 1) The Offline Inspector Mobile Application allows inspectors to see the location of the next appointment and upload inspection results and 2) the Out of the Box Salesforce App allows users to see data In Salesforce (Previous Inspections, etc). The client understands that users may need to use two separate applications and that some information may not be available in the two apps.
Geolocation and Address Validations are required. RLD will contract access with a cloud based GIS API platform. This API will provide address validation information and official address formatting. The online GIS API has a yearly fee that has been included in the Licensing fees of this proposal.
File preview is not required for all files (some file types may not be supported and some files will be too large to preview). The end user will need to click on a file to download the file to their computer and view it.
All Permits will be migrated. Inactive Licenses will not be migrated. Previews payment records will not be migrated. ANM and RLD will consider the option of data being available in Salesforce via an API integration (not migrated into the database).
RLD will be responsible for Data Clean Up and Preparation. RLD will provide the Data Exported from Kiva and CMS in CSV Files that are ready to be imported. RLD will be responsible for the accuracy of the Data in the CSV Files.
RLD will be responsible for making sure the information in the Accela Database is accurate before it is transferred to Salesforce.
RLD will be responsible for migrating files (documents) from Accela, Kiva and CMS to Salesforce. The migration of these files may need to be performed manually and may take a considerable amount of time.
PAGE | 6
NUMBER DESCRIPTION
Refunds will be entered manually in the system. The money transaction will occur outside the System (Refunds will not be generated by the Chargent Application).
Addresses for permits in Accela will be migrated as-is, if the addresses are not validated in Accela they will be transferred with the same information to Salesforce.
Payment card transactions will be processed only with Cybersource and Paypal.
Pre-Paid Accounts will be managed manually. Contractors may submit payment with check or money order and an internal user will create the pre-paid record in Salesforce. Payments processed online will be automatically discounted from the Pre-Paid Account.
There is no need to integrate financial information to an ERP System.
The CTI integration with the phone system is optional and is not in the scope of the Phase 1 of this project.
Internal Users will be able to utilize modern web browsers (ie. Chrome, Firefox) to access the internal Salesforce Application. The list of browsers supported by the Salesforce application is listed below. Users accessing the portal with an unsupported browser will receive an error message asking the user to use a modern web browser.
Authentication will be performed by Active Directory and the client has an ADFS System in place that can be configured for SAML Authentication. If an ADFS Server is not available, Active Directory authentication will not be possible.
The PSI and the MLO files will be generated in a format that can be used to upsert license information in Salesforce.
The plan review workflow will be at the permit level. The permit application will be routed through a plan review workflow and all files attached to the permit will be routed with that permit.
Only 20 Internal users require write access to the folders where Contractors will be uploading documents. All other users only need read-only access. Inspector will upload pictures to a separate repository and these pictures will not be in the same folder as the documents uploaded by the Contractors.
If a contractor works for two separate organizations, he/she would need to have one login for each organization.
PAGE | 7
NUMBER DESCRIPTION
Delegated Administration (Contractors approving / removing other company members accounts) is not required.
If a user logins with an unsupported browser, the system will display a message asking the user to login with a supported browser
Field Services Lightning App supports Android v4.4 or later, and iOS 9.3 or later
RLD understands the limitations that come with the Field Service Android App and the Field Service iOS App
The Standard Salesforce Encryption (128 bit AES) is sufficient to store Social Security Information (if Social Security Numbers must be stored in the System) for End Users
Person Accounts are not required for this project. Everyone requesting a Permit represents a business and do not request a Permit for an individual.
With the Customer Community License, external users must have one unique email for each account (Vendor Requesting a Permit). If an end user must manage permits for multiple Vendors, this end user would need a username (with different email address) for each different Vendor. The feature to support one contact for multiple accounts is only supported in the Customer Community Plus account.
The scope of this project includes the creation of the community starting with a login page for a vendor to login to the portal. The creation of an external website (for non-authorized users) is not included as part of the scope of this project. RLD will provide a link to an external facing website to redirect users to the login page of the portal.
Most of the implementation of this project will be performed remotely. ANM will be onsite for design meetings, status updates that require onsite presence and training. But most of the development and planning sessions will occur remotely using a Web Conferencing Tool.
There is no need to implement a Data Integration / Update process for Accounts (Vendors), Contacts and/or Permits once the initial data migration has been completed.
These are the number of licenses required for this project, if additional licenses are required, the client will procure these licenses separately:
PAGE | 8
NUMBER DESCRIPTION
RLD will use one of the payment gateways that are supported by Chargent.
Inspections will be scheduled manually by an internal Scheduler. Inspections will not be scheduled automatically or by the community users.
Client will be responsible for the installation of the mobile apps in mobile devices. Client will be responsible for providing the end users with mobile devices that are supported by Salesforce. Issues with applications loading slowly in older devices is not included in the scope of the project.
ANM will provide 2 days of training sessions in a location indicated by the Client (Albuquerque or Santa Fe). Client will be responsible for training other users in a train the trainer scenario.
1.6 INITIAL PROJECT RISKS IDENTIFIEDThe project team has identified the following risks.
1.6.1 EXTERNAL RISKS
RISK PROBABILITY& IMPACT MITIGATION PLAN
Vendor abandonment (software development): If the contracted vendor were to abandon the project then the project would be halted or seriously delayed.
L/H The vendor RLD selects will be required to follow industry standards. If the vendor were to abandon the project early in the process, before funds were used then another developer could be brought in. If the vendor were to abandon the project late in the development process it would be possible for existing RLD IT staff, along with another vendor, to finish the required software development work to finish the
PAGE | 9
project due to the project having followed industry standards. It will be non-proprietary software that RLD owns and fully controls, unlike the current Accela implementation which is proprietary black box technology and requires Accela engineers to make programming changes. If neither of these were feasible we would need to turn to one of the other alternatives listed.
Vendor abandonment (payment page provider): If Wells Fargo/CyberSource, our payment page provider, were to remove or significantly alter their hosted payment page service then additional development work may be required to adapt to new provider or to the page changes.
L/M Payment gateway providers are numerous and our financial service provider would likely have a new recommended payment page host. RLD IT would likely be able to make the small required changes to the application to accommodate a different payment page host given that most of the initial integration has been completed.
PCI compliance standard changes: Security standards are, by their very nature, subject to ongoing change. If the PCI compliance requirements were to change in a significant way then additional work and\or funding would be needed to adapt to the change.
M/M RLD IT staff will need to keep a close watch on how PCI compliance requirements and items change over time. This time estimate is built into our maintenance hours estimations. Usually, these standards give sufficient lead time to make changes in time to remain compliant.
PAGE | 10
1.6.2 INTERNAL RISKS
RISKPROBABILIT
Y& IMPACT
MITIGATION PLAN
Inadequate or incomplete requirements gathering: If project requirements are not fully understood or updated early in the process the final product may not address the true needs of the project or additional time or funding would be required to remedy the situation.
L/H Project management would occur both inside the contracted organization and from RLD IT with cross-checking occurring between each organization throughout the requirements gathering and design phases. This has worked well in past endeavors.
Loss of key staff: Application and business process knowledge exists in only one or two individuals, depending on knowledge type. If one of the key individuals were to leave during key points in the project the finished product might not be adequate to the task and resulting in delayed project implementation.
M/H Inclusion of multiple RLD IT, CID and MHD personnel during requirements gathering and design phases along with good written documentation of requirements and split project management between external and internal entities will ensure that there are multiple sources for all key project knowledge.
High staff utilization: If key staff are over-utilized and cannot properly contribute to key phases then a poor final product could result or be delayed resulting in delayed project implementation.
H/L Since the recommended alternative relies primarily on an external vendor already deeply familiar with the product the risk of unavailable staffing is greatly reduced to only the requirements, design, and, to some extent, the testing phases.
Critical bug or flaw discovered: If a critical bug or flaw is discovered in the existing Permitting and Licensing portal application or in the new development the application could be rendered unusable or deemed unreliable.
L/H Our proposed service contract will cover bugs and flaws discovered. If the vendor should fail to honor this service contract and/or fail to fix the discovered flaw then RLD IT may be able to fix the flaw on its own or an additional external developer would need to be engaged due to the fact the contractor will be using industry standards.
PAGE | 11
2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE
2.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.
NAME STAKE IN PROJECT ORGANIZATION
TITLE
Richard Lucero Permitting Front Desk Supervisor RLD CID Bureau Chief
Jesus Carrasco Manufactured Housing Department (MHD) supervisor
RLD MHD Bureau Chief
Clay Bailey LP Gas RLD LP Gas Bureau Chief
Robert Unthank Executive Sponsor RLD Superintendent
2.2 PROJECT GOVERNANCE STRUCTURE
PAGE | 12
2.2.1 DESCRIBE THE ORGANIZATIONAL STRUCTURE – ORG CHART
2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE
EXECUTIVE SPONSOR – ROBERT UNTHANK, SUPERINTENDENT, RLDRLD BUSINESS OWNER - ROBERT UNTHANK, SUPERINTENDENT, RLDMHD BUSINESS OWNER – JESUS CARRASCO, MHD BUREAU CHIEF
LPG BUSINESS OWNER – CLAY BAILEY, LPG BUREAU CHIEF
CMS BUSINESS OWNER – AMANDA ROYBAL, CMS BUREAU CHIEF
PRM BUSINESS OWNER – RICHARD LUCERO, PRM BUREAU CHIEF
AGENCY CIO/IT LEAD – MICHELLE LANGEHENNIG, CIO, RLDPROJECT MANAGER – FABIO MIR, APPLICATION DEVELOPER, RLD
2.2.3 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES
The key interface between ANM and RLD is between the RLD Project Manager, Fabio Mir, and the Project Manager from ANM and between the RLD Project Manager and the assigned Team Leaders. The primary methods utilized will be the Status Report/Briefing, ad-hoc meetings, electronic mail, and phone conversations. Interaction may occur directly between the technical components of all teams. However, overall task direction can only come from the Project Manager. Final decisions will be made at the Steering Committee level.
PAGE | 13
2.3 EXECUTIVE REPORTINGWeekly meetings will be scheduled between RLD and ANM. Discussions will center around: milestones, deliverables, schedules and hard stops. These meetings will be either in-person or through phone/web conference, depending on the needs and availabilities at the time. RLD CIO will report to senior management weekly staff meeting.
3.0 SCOPE
3.1 PROJECT OBJECTIVES3.1.1 BUSINESS OBJECTIVES
NUMBER OBJECTIVE
1 Migrate current proprietary software code based Accela implementation to code based application that is configured and controlled by RLD.
2 Maintain PCI DSS 3.2 compliance through the life of the Permitting and Licensing program and for as long as the PCI DSS compliance specification is relevant.
3 Maintain or increase the percentage of Business Services transactions that can be customer initiated and handled online and outside of regular business hours. Customer initiated, online transactions reduce the burden on the RLD Business Services staff, reduce costs, increase customer convenience and are, overall, desirable.
5 Maintain or increase the ease-of-use and ease-of-payment in the Permitting and Licensing portal application. It is important that becoming PCI DSS compliant not negatively impact Permitting and Licensing application convenience or availability.
3.1.2 TECHNICAL OBJECTIVES
NUMBER DESCRIPTION
TECHNICAL OBJECTIVE 1
Create online permitting application using industry-standard coding and best practices standards.
PAGE | 14
NUMBER DESCRIPTION
TECHNICAL OBJECTIVE 2
Create robust data repository for the permitting application program following best practices standards.
TECHNICAL OBJECTIVE 3
Create a very user-friendly public facing interface.
TECHNICAL OBJECTIVE 4
Create an easy to use day-to-day operations interface.
TECHNICAL OBJECTIVE 5
Create a comprehensive administration interface.
TECHNICAL OBJECTIVE 6
Create a mobile interface for the inspectors.
TECHNICAL OBJECTIVE 7
Create an easy way to create new permits or record types.
TECHNICAL OBJECTIVE 8
Ensure the replacement programs has an unlimited upload document size.
3.2 PROJECT EXCLUSIONSNo exclusions
3.3 CRITICAL SUCCESS FACTORS
NUMBER DESCRIPTION
QUALITY METRICS 1
Measured by percentage of transactions initiated and processed through the online Permitting and Licensing portal.
QUALITY METRICS 2
Measured by number of requests for assistance and complaints as a percentage of total transactions successfully processed.
4.0 PROJECT DELIVERABLES AND METHODOLOGY
4.1 PROJECT MANAGEMENT LIFE CYCLE
PAGE | 15
Phase Summary of Phase Key Deliverables
Planning Acquire the software and licensing to implement the permitting and inspection software for construction industries.
Software
licensing
Planning Gather requirements and design workflows for 10 permit types. Select one permit type as a pilot for Go-Live.
Design integration interfaces and data migration strategy for the selected permit from Accela SQL Database to new application.
Implementation Develop application and Contractors Portal with design information for 10 Permit Types.Integrate PSI’s License Import text file, credit card transactions, Geolocation used by inspector’s and document management (plans for plan review and historical documents). Migration of permit records for one permit type from Accela to new application. Configuration of Inspection Software and Mobile Application for one permit type.
Go Live with one permit type.
4.1.1 PROJECT MANAGEMENT DELIVERABLES
The following deliverables have been identified.
4.1.1.1 Project Management PlanDescription - Deliverable Acceptance Criteria
Completed Project Management PlanStandards for Content and Format -
Meets DoIT PMP Template requirementsQuality Review -.Key stakeholders review the PMP document.
PAGE | 16
4.1.1.2 Project PlanDescription - Deliverable Acceptance Criteria – Completed Project Plan
Standards for Content and Format – Microsoft Project Plan
Quality Review – Reviewed by key stakeholders
4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS
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
PRJ-DEL-001 Project Management Plan (PMP)
Martin RomeroJesus CarrascoMichelle LangehennigFabio Mir
PRJ-DEL-001 Project Plan (PP) Martin RomeroJesus CarrascoMichelle LangehennigFabio Mir
4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE The following procedure will be used for the formal acceptance of all deliverables.
1. Deliverables will be submitted by ANM to RLD Project Manager and project team for review.
2. The RLD PM will distribute the deliverable to additional subject matter experts, as applicable, and coordinate feedback to ANM.
3. ANM will incorporate review comments/suggestions. 4. Upon closure of all feedback, the RLD Business Owner and Project Manager will sign
off on the reviewed deliverables as part of Deliverable acceptance procedure.
4.2 PRODUCT LIFE CYCLE
Phase Summary of Phase Key Deliverables
Planning Initial Business Analysis & Kickoff
Acquire the software and licensing to implement the permitting and inspection software for construction industries.
Planning Project Management Gather requirements and design workflows for 10 permit types.
PAGE | 17
Select one permit type as a pilot for Go-Live.
Design integration interfaces and data migration strategy for the selected permit from Accela SQL Database to new application.
Implementation System Requirements & Design Documentation
System Configuration
System Development & Deployment
Training
Develop application and Contractors Portal with design information for 10 Permit Types.Integrate PSI’s License Import text file, credit card transactions, Geolocation used by inspector’s and document management (plans for plan review and historical documents). Migration of permit records for one permit type from Accela to new application. Configuration of Inspection Software and Mobile Application for one permit type.
Go Live with one permit type.
4.2.1 TECHNICAL STRATEGY
Technical Strategy for Configuration is listed in detail in the ANM Statement of Work document.
4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES
Product Deliverables are work products or artifacts that are driven by the product management methodology requirements and standard project management practices regardless of the product requirements of the project.
4.2.2.1 Permitting Application DesignDescription – Design of Permitting Application based on 10 Permit Types
Deliverable Acceptance Criteria - defined understanding of the system design for permitting application. Application Design Document with Information from Workshops for 10 Permit Types and Go-Live Plan for one Permit Type.Standards for Content and Format -
Understandable to key stakeholdersQuality Review -
Key Stakeholders accept it.
PAGE | 18
4.2.2.2 Permitting ApplicationDescription - One Permit Type Active in Production Environment of Permitting Application
Deliverable Acceptance Criteria - Application Delivered and Active in Production Environment for One Permit Type. Data Migration (or Integration) for the one permit type from Accela to Salesforce. Integrations for Document Management, Credit Cards and Geo Location Completed.
Standards for Content and Format – Design Document
Quality Review – User Acceptance Criteria
4.2.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS
DELIVERABLE NUMBER
DELIVERABLE APPROVERS (WHO CAN APPROVE)
DATE APPROVED
1 Permitting Application Design Martin RomeroJesus CarrascoMichelle LangehennigFabio Mir
2 Permitting Application Martin RomeroJesus CarrascoMichelle LangehennigFabio Mir
4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE
The RLD will use a project milestone document and the deliverables described in the executed contract. The RLD business project manager, RLD CIO and business owner will sign off on all completed deliverables in the contract.
5.0 PROJECT WORK
5.1 WORK BREAKDOWN STRUCTURE (WBS) The WBS is as noted in Section 5.2. Bold groupings indicate the major WBS categories for this project.
5.2 SCHEDULE ALLOCATION -PROJECT TIMELINE The table below provides a high-level view of the project time line.
A more detailed project schedule to this plan will be provided once the system landscape becomes available and will be managed and version-controlled outside of the PMP.
PAGE | 19
o Deliverable 1 – Included in this Scope of Work – ANM will hold workshop meetings with RLD Project Stakeholders. One Permit Type will be selected to activate in a Production Environment. ANM will configure all integrations during this phase including Licensing, Credit Card Transactions, Geo Location, etc. ANM will design the implementation of the Solution based on 10 Permit Types.
o Deliverable 2 – Included in this Scope of Work - Only data from Accela for this 1 Permit Type will be transitioned to Salesforce (some data may be migrated and some data may be made available, details to be determined). One Permit Type will be active in a live production environment.
o Deliverable 3 – Not Included in this Scope of Work – ANM will finalize the design for the 30 remaining permit types.
o Deliverable 4 – Not Included in this Scope of Work - Migrate the remaining 39 Permit Types to Production in the Salesforce Platform. Data for all permit types from Accela will be transitioned to Salesforce (some data may be migrated and some data may be made available, details to be determined).
o Deliverable 5 – Not Included in this Scope of Work – ANM will design the Compliance Application in Salesforce.
o Deliverable 6 – Not Included in this Scope of Work – ANM will implement the Compliance Application in Salesforce. Data from CMS and KIVA application will be transitioned to Salesforce (some data may be migrated and some data may be made available, details to be determined).
o Deliverable 7 – Not included in this Scope of Work – Ongoing Support for moves, adds and changes is included for 8 months. The remote support does not include new customizations that require software development.
5.3 PROJECT BUDGET
Phase / Activity Associated Deliverables Estimated Budget
Phase 1 Acquire the software and licensing to implement the $413,000
PAGE | 20
Phase / Activity Associated Deliverables Estimated Budget
Planning permitting and inspection software for construction industries.
Phase 2Planning
Gather requirements and design workflows for 10 permit types. Select one permit type as a pilot for Go-Live.Design integration interfaces and data migration strategy for the selected permit from Accela SQL Database to new application.
$195,000
Phase 3Implementation
Develop application and Contractors Portal with design information for 10 Permit Types.Integrate PSI’s License Import text file, credit card transactions, Geolocation used by inspector’s and document management (plans for plan review and historical documents). Migration of permit records for one permit type from Accela to new application. Configuration of Inspection Software and Mobile Application for one permit type. Go Live with one permit type.
$359,000
TOTALS $967,000
5.4 PROJECT TEAM5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE
See Section 2.2.1
5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES
ROLE RESPONSIBILITY NAME FUNCTIONAL AREA
Executive Sponsor
Ensure project funding. Approve any changes to project plan or scope. Communicate with Project Manager the status of project.
Mike Unthank Cabinet Secretary
Business Owners Part of the business requirements gathering and verifying that the progress is headed in an acceptable direction.
Martin RomeroJesus CarrascoClay BaileyAmanda RoybalRichard Lucero
Division Directors
PAGE | 21
ROLE RESPONSIBILITY NAME FUNCTIONAL AREA
User Acceptance Team
Formal acceptance of project deliverables.
TBD Cross-Functional
Operations Team Team dedicated to ensuring testing and project is moving forward efficiently. Could be managers of internal users to encourage their staff to complete their user acceptance testing
TBD Cross-Functional
Application Support Team
Internal IT Applications Developers
Chuck SlocterAmanda Urioste
Fabio Mir
Applications Development
IT Project Management
Vendor Team Team of Vendors implementing Salesforce
SalesforceANM
Cross-Functional, representing application development, project management and training
5.5 STAFF PLANNING AND RESOURCE ACQUISITION
PAGE | 22
5.5.1 PROJECT STAFF
Resource Cost Estimate
Estimated Hours Availability Skill Set Work Product/Deliverable
Salesforce $413,000 Per Contract
Salesforce Platform Licensing
Per Contract
ANM $554,000 Per Contract
Salesforce Development, Project Management, Training
Per Contract
5.5.2 NON-PERSONNEL RESOURCES
Resource Cost Estimate
Estimated units/hours Availability Source Work Product/Deliverable
N/A
5.6 PROJECT LOGISTICS5.6.1 PROJECT TEAM TRAINING
ResourceCost Estimate
Estimated Hours Availability Skill Set Work Product/Deliverable
N/A
6.0 PROJECT MANAGEMENT AND CONTROLS
6.1 RISK AND ISSUE MANAGEMENTThe Project will be structured using a mixture of process-based and agile approaches. In addition, project reporting structures will be adjusted to meet timelines and phase gates defined by the Project Certification Committee.
6.1.1 RISK MANAGEMENT STRATEGY
Risks will be tracked and monitored throughout the entire project life-cycle. Risks may be contractual or technological. Risks may also come in the form of specification ambiguity, technical uncertainty, technical obsolescence, or new technology. Technical risks often occur because a problem is harder to visualize or solve than originally thought. This risk can be attributed to several factors such as the size and complexity of the project, resource issues, new
PAGE | 23
software versions, client acceptance and management, subcontractor reliability, or problematic source materials.
Risks come and go throughout the project life-cycle. Each risk identified will be tracked with a contingency plan or course of action and updated on a regular basis in the bi-weekly as-needed risk/issue log updates, as well as the monthly ESC meetings.
All tracked project risks will be maintained in a project risk log, which will be updated as-needed through the life of the project, and version-controlled in the project repository.
6.1.2 PROJECT RISK IDENTIFICATION
The risks will be identified by using a Risk Assessment Tool developed in Microsoft Excel. This is the primary tool to be used to list and categorize project risks. The sequence of activity is as follows; Risk Identification, the process of identifying potential risks and commenting the specific characteristics of each, followed by periodic monitoring and execution of mitigations and/or contingencies when required.
6.1.3 PROJECT RISK MITIGATION APPROACH
All identified risks will have appropriate mitigation strategies/plans. For those risks that are highly probable and have significant impact to the project, the project team will develop contingency plans.
6.1.4 RISK REPORTING AND ESCALATION STRATEGY
Risk monitoring and control will be part of every project status meeting. Risk identification will be the responsibility of all members of the project team. The Business Owner and Project Manager will be responsible for tracking risks and for developing mitigation strategies and contingency plans that address the risks identified by the team.
This project will follow a continuous risk management strategy. Risk will be assessed routinely to ensure that identified risks are being dealt with appropriately and that new risks are identified and dealt with as early as possible.
6.1.5 PROJECT RISK TRACKING APPROACH
The Project Risks identified in the above mentioned Excel Spreadsheet will be tracked utilizing a shared version of the spreadsheet on a SharePoint site, so that RLD and the vendors have a centralized place to track these risks.
PAGE | 24
6.1.6 ISSUE MANAGEMENT
6.1.6.1 Internal Issue Escalation and Resolution ProcessRefer to above flowchart.
PAGE | 25
6.1.6.2 External Issue Escalation and Resolution ProcessIssue management and escalation will follow a similar escalation schema as described in Section 6.1.6.1.
6.2 INDEPENDENT VERIFICATION AND VALIDATION - IV&VRLD is currently deciding on an independent third party to provide Independent Validation and Verification (IV&V) on this project. The IV&V contractor will be provided with copies of all deliverables under this SOW.
Project/Product Area Include –Yes/No
Project Management Yes
Quality Management Yes
Training Yes
Requirements Management Yes
Operating Environment Yes
Development Environment Yes
Software Development Yes
System and Acceptance Testing Yes
Data Management Yes
Operations Oversight Yes
Business Process Impact Yes
6.3 SCOPE MANAGEMENT PLAN
PAGE | 26
6.3.1 CHANGE CONTROL
6.3.1.1 Change Control ProcessThe vendor Project Manager(s) shall conduct an impact analysis to determine the impact of the change on scope, time and cost of the project. The change request and impact analysis will be used in determining if the change request can be achieved. For an approved change request, the vendor Project Manager will deliver an initial response on the Change Request form that will include the following:
PAGE | 27
Estimated date by which change will be completed if approved Change request number High level assessment of the impact of the change (anticipated price impact, anticipated
schedule impact), and consequential changes to the Scope of Work Requested approvals from specified project team members.
The Change Request form will include the following information: Date submitted Change category Description of change Events that made change necessary/desired.
The vendor Project Manager may use their own Change Request format, should one exist, as long as it includes the information above. If one does not exist, they may use the NMDOT standard format, if desired.
6.3.1.2 Change Control Board (CCB)The project shall follow a two-level CCB schema. The Executive Sponsors, Business Owners, Project Manager, and Chief Information Officer (CIO) will function as the CCB for the project, for any changes that may require an amendment to the contract(s). Less significant changes, including minor adjustments to deliverable timelines and content, may be approved by a CCB composed of the Business Owner and Project Managers.
- Any change which increases the overall cost of the project will require approval by the Executive Sponsors and/or CIO.
- CCB discussion and decisions shall be documented in meeting minutes for the Executive Sponsors, CIO and Business Owners.
- Discussion and approval/disapproval of less significant changes by the Business Owner and Project Managers shall be documented either in meeting minutes or via email.
- Changes to downstream documentation, requirements and training docs and schedule, for example, shall be made once a change is approved.
6.4 PROJECT BUDGET MANAGEMENT6.4.1 BUDGET TRACKING
The budget will be tracked by the Project Manager and budget tracking updates will be provided on a monthly basis utilizing excel spreadsheets and the SHARE financial system. Monthly budget reporting to DoIT will be managed by the IT Project Manager and verified by the Business Owners and Project Manager.
PAGE | 28
6.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 COMMUNICATION MATRIX
Communication Type
Objective of Communication
Medium Frequency Audience Owner Deliverable
Initial Logistical Kickoff Meeting
Introduce the project team and the project. Review project objectives and management approach.
- Conference Call
Once - Project Team Vendor Project Manager
- Meeting Minutes- PMP- Issue tracking system & other documentation templates as needed
Business Analysis & Project Kickoff
In-depth review of business processes & needs across all stakeholders. Formal project kickoff across full project team.
- Face to Face Once - Project Sponsor- Project Team- Stakeholders
Vendor Project Manager
- Meeting Minutes- Baseline project schedule- Updated PMP
Project Team Meetings
Review status of the project with the team.
- Face to Face- Conference Call
Bi-Weekly - Project Team Project Managers
- Meeting Minutes- Updated Project Schedule & issue/risk log
IT Project Reports
Report the status of the project including activities, progress, costs and issues.
- Email Bi-Weekly
Monthly (ESC Report)
- Business Owner- IT Leadership
IT Project Manager
- Project Status Report
ESC Project Status Reports
Report the status of the project including activities, progress, costs and issues.
Conference call and email
Monthly - Project Sponsor- Project Team
Business Project Manager
- Project Status Report- Project Schedule
DoIT Monthly Status Reports
Report the status of the project, including progress, cost, performance to budget and risk.
Email Monthly - DoIT- PCC - General Public
IT Project Manager
Monthly Report
External Report progress and Conference Monthly External Business Meeting Minutes
PAGE | 29
stakeholder updates
solicit input from stakeholders as project proceeds
call or email Stakeholders owner
6.5.2 STATUS MEETINGS
Weekly project status meeting will be held every Thursday that will report RLD’s project progress, issues and design product demonstration throughout the lifecycle of the project.
6.5.3 PROJECT STATUS REPORTS
The following status reports will be delivered throughout the life of the project:
Contractor weekly status report to RLD-IT
Monthly Status Report to Business Owners provided by PM.
IV&V Reports to Business Owners, CIO, & EPMO
Monthly report to DoIT
Ad-hoc reports as necessary
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.
6.6.1 BASELINES
Project Area Category Measure
Project Management Task performance On Schedule
Quality Errors in Data Modeling Errors by functional area
Testing (Data Warehouse) Performance and Quality Accepted/Not Accepted
Implementation Quality Data A final data feed from the Subject Matter Expert (SME) that is accurate and complete.
PAGE | 30
6.6.2 METRICS LIBRARY
A monthly analysis of performance and cost metrics will be calculated and reported to IT Leadership, this information will also be reported to the Business Owners on a quarterly basis.
6.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 QUALITY STANDARDS
Each functional organization is responsible for the quality of its contribution to the project and will apply its internal quality standards to project products and services. The project team will assess the project’s products and services based on the standards established by the functional organizations represented on the project.
There are number of ways that quality has been built into this project. The first is IV&V, which will make sure the project meets expected requirements through a third party evaluation of the project. The second is the integrated project control process and change control process, which assure that any changes made to the project are executed in a structured manner. The change control process minimizes change of scope to the project and, if scope does change, it is done with a clear understanding of impact to the project. The third process for quality management is the risk management plan, which measures, mitigates and includes contingency plans for each risk.
The project team will create lessons learned at the end of the project. These lessons learned will be incorporated into subsequent phases, if any, of the project and be part of the project library that will be available for future projects to use.
All of these processes combined will create a product with quality that is built in, not tested in after the fact, and will provide an environment that maximizes opportunities to control quality.
No. Quality Standard Tracking Tool or Measure
1 Project phase is completed by the established finish date. Project ScheduleProject Status
2 Project is completed within budget. Project CharterProject Status
3 Monthly project reviews show contractors deliver requirements specified in the contract by due dates.
Vendor ContractCustomer ApprovalsProject Schedule
4 Project issues are resolved and documented within specified time limits, or extensions are justified.
Issue Tracking
5 Project will be completed based on the original project scope and approved scope changes.
Project CharterProject PlanChange Request(s)
PAGE | 31
6.7.2 PROJECT AND PRODUCT REVIEW AND ASSESSMENTSReview Type Quality Standard Tools Reviewer Reports
Peer Reviews Per deliverable Checklists anddeliverableacceptance criteria
Teammembers
Edited /commenteddeliverable
Testing System andAcceptance TestCycles
Test scripts andCases.Test Plans.Automated testScripts.
Teammembers
Test Results
Internal Audits Closeout tasks Projectdocumentation andcommunicationreview.
RLD PM , ANM/Salesforce Project Team
Lessons Learned,Phase CloseoutReports
6.7.3 AGENCY/CUSTOMER SATISFACTION
Areas of feedback When How Often
Agency awareness Meeting to go over the status of the project
Weekly
Quality of communications Contractor is always available to call or emails
Weekly
Manages project tasks Has been keeping a running log of all the items to ensure RLD questions and concerns are addressed
Weekly
Productive Meetings Meetings held weekly and RLD updated with system configuration assignments
Weekly
6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESSThe RLD Chief Information Officer will take delivery of any required media; manuals; contracts; licenses; services agreements; configuration settings; status of patches; in-house or vendor developed code; test cases, routines, and scripts; and other items required for the project. The RLD CIO will take delivery of such products only after the product deliverables have been accepted by the RLD Business Owners.
PAGE | 32
Deliverable Final Approval Process Customer Acceptance Criteria
Scoping Session Signature approval by Business Owners Receipt of Scope of Work Documentation
IV&V Signature approval by Business Owners Receipt of Initial and Final Reports with 4 Interim Reports.
Software Signature approval by Business Owners Purchase of Software
Planning and Installation Signature approval by Business Owners Loaded software onto landscape and receive discovery workshop scoping document
Design Document Signature approval by Business Owners Receipt of Business System Design Documents
Configuration and Building Signature approval by Business Owners Documents reviewed and approved by designated RLD representatives.
Testing Signature approval by Business Owners Test results are reviewed and approve by designated RLD representatives
Training Signature approval by Business Owners Training documents produced in accordance with curriculum outlined in the Training Plan. Document reviewed and approved by designated RLD representative.
Identified Training Sessions completed.
Go-Live Signature approval by Business Owners All defined acceptance forms signed by designated RLD representative.
Project Management Signature approval by Business Owners All defined acceptance forms signed by designated RLD representative.
Cloud Hosting and Warm Storage
Signature approval by Business Owners Executed Contract and Maintenance Agreement
6.8 CONFIGURATION MANAGEMENTConfiguration Management (CM) is a systems engineering process for establishing and maintaining consistency of a product’s performance, functional and physical attributes with its requirements, design and operational information throughout its life.
Over the course of the implementation of the Accela Replacement configuration management will be performed by:
• Establishing software requirements traceability – the functional and technical requirements will be mapped to each item in the Business System Design (BSD) Documents.
• All changes to the system will be subject to system and user acceptance testing.
PAGE | 33
• Documentation to be provided to RLD on the usage and functionality of the Accela Replacement as well as for all changes implemented to meet RLD specific requirements. This documentation will include the configuration and training documentation. Documentation will be version-controlled.
A Transition Plan to be prepared for the transition of the system’s support from the Project Team to the Client Care Team. This plan will outline the Client Care processes.
6.8.1 VERSION CONTROL
A methodology for version control of the configuration changes and customizations shall be documented as part of the business procedures and policies created in this project.
6.8.2 PROJECT REPOSITORY (PROJECT LIBRARY)
A SharePoint project repository will be used as a means to provide a central repository for all project documentation and deliverables.
6.9 PROCUREMENT MANAGEMENT PLANAll procurement for project goods and services must be performed under the guidance and direction of New Mexico State Procurement Statues.
PAGE | 34
7. 0 PROJECT CLOSE
7.1 ADMINISTRATIVE CLOSE
Administrative Close will occur at the end of phase and end of project. This closure consists of verification that objectives and deliverables were met, and transition to the next phase via formal review with the Project Certification Committee. All deliverables are formally accepted, once all feedback and issues are closed.
End of project closure consists of phase closure of the Implementation Phase, along with formal Go/NoGo review amongst the project team, Executive Sponsors and vendor to transition from Production to Maintenance, as well as compilation of final project lessons learned and ROI analysis. Formal closure with the Project Certification Committee will occur once administrative end of project closure is complete.
PAGE | 35
7.2 CONTRACT CLOSE
Contract close for this project will comply with all State and RLD procedures for contract close.
ATTACHMENTSNone.
PAGE | 36
