Executive Sponsor – robert unthank, Superintendent, RLD



RLD Accela Replacement ProjectPROJECT 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, 2018Revision: 1.1 TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc515964524" Revision History PAGEREF _Toc515964524 \h 31.0 Project Overview PAGEREF _Toc515964525 \h 41.1Executive Summary- rationale for the Project PAGEREF _Toc515964526 \h 41.2 funding and sources PAGEREF _Toc515964527 \h 41.3 constraints PAGEREF _Toc515964528 \h 51.4 dependencies PAGEREF _Toc515964529 \h 51.5 ASSUMPTIONS PAGEREF _Toc515964530 \h 51.6 Initial Project Risks Identified PAGEREF _Toc515964531 \h 91.6.1 External Risks PAGEREF _Toc515964532 \h 91.6.2 Internal Risks PAGEREF _Toc515964533 \h 112.0 Project Authority and Organizational Structure PAGEREF _Toc515964534 \h 122.1 Stakeholders PAGEREF _Toc515964535 \h 122.2 Project Governance Structure PAGEREF _Toc515964536 \h 122.2.1 Describe the organizational structure – Org Chart PAGEREF _Toc515964537 \h 132.2.2 Describe the role and members of the project steering committee PAGEREF _Toc515964538 \h 132.2.3 Organizational Boundaries, interfaces and responsibilities PAGEREF _Toc515964539 \h 132.3 Executive Reporting PAGEREF _Toc515964540 \h 143.0 Scope PAGEREF _Toc515964541 \h 143.1 Project Objectives PAGEREF _Toc515964542 \h 143.1.1 Business Objectives PAGEREF _Toc515964543 \h 143.1.2 Technical Objectives PAGEREF _Toc515964544 \h 143.2 Project exclusions PAGEREF _Toc515964545 \h 153.3 Critical Success Factors PAGEREF _Toc515964546 \h 154.0 Project Deliverables and methodology PAGEREF _Toc515964547 \h 164.1 Project Management Life Cycle PAGEREF _Toc515964548 \h 164.1.1 Project Management Deliverables PAGEREF _Toc515964549 \h 164.1.2 Deliverable Approval Authority Designations PAGEREF _Toc515964550 \h 174.1.3 Deliverable Acceptance Procedure PAGEREF _Toc515964551 \h 174.2 PRODUCT LIFE CYCLE PAGEREF _Toc515964552 \h 174.2.1 Technical Strategy PAGEREF _Toc515964553 \h 184.2.2 Product and Product Development Deliverables PAGEREF _Toc515964554 \h 184.2.3 Deliverable Approval Authority Designations PAGEREF _Toc515964555 \h 194.2.4 Deliverable Acceptance Procedure PAGEREF _Toc515964556 \h 195.0 Project Work PAGEREF _Toc515964557 \h 195.1 Work Breakdown Structure (WBS) PAGEREF _Toc515964558 \h 195.2 Schedule allocation -Project Timeline PAGEREF _Toc515964559 \h 205.3 Project Budget PAGEREF _Toc515964560 \h 205.4 Project Team PAGEREF _Toc515964561 \h 215.4.1 Project Team Organizational Structure PAGEREF _Toc515964562 \h 215.4.2 Project Team Roles and Responsibilities PAGEREF _Toc515964563 \h 215.5 STAFF PLANNING AND Resource ACQUISITION PAGEREF _Toc515964564 \h 225.5.1 Project Staff PAGEREF _Toc515964565 \h 235.5.2 Non-Personnel resources PAGEREF _Toc515964566 \h 235.6 PROJECT LOGISTICS PAGEREF _Toc515964567 \h 235.6.1 Project Team Training PAGEREF _Toc515964568 \h 236.0 Project Management and Controls PAGEREF _Toc515964569 \h 236.1 Risk and issue Management PAGEREF _Toc515964570 \h 236.1.1 Risk Management Strategy PAGEREF _Toc515964571 \h 236.1.2 Project Risk Identification PAGEREF _Toc515964572 \h 246.1.3 Project Risk Mitigation Approach PAGEREF _Toc515964573 \h 246.1.4 Risk Reporting and Escalation Strategy PAGEREF _Toc515964574 \h 246.1.5 Project Risk Tracking Approach PAGEREF _Toc515964575 \h 246.1.6 ISSUE MANAGEMENT PAGEREF _Toc515964576 \h 256.2 INDEPENDENT Verification And Validation - Iv&V PAGEREF _Toc515964577 \h 266.3 Scope Management Plan PAGEREF _Toc515964578 \h 266.3.1 Change Control PAGEREF _Toc515964579 \h 276.4 Project Budget Management PAGEREF _Toc515964580 \h 286.4.1 Budget Tracking PAGEREF _Toc515964581 \h 286.5 Communication Plan PAGEREF _Toc515964582 \h 296.5.1 Communication Matrix PAGEREF _Toc515964583 \h 296.5.2 Status Meetings PAGEREF _Toc515964584 \h 306.5.3 Project Status Reports PAGEREF _Toc515964585 \h 306.6 PERFORMANCE MEASUREMENT (PROJECT METRICS) PAGEREF _Toc515964586 \h 306.6.1 Baselines PAGEREF _Toc515964587 \h 306.6.2 Metrics Library PAGEREF _Toc515964588 \h 316.7 QUALITY OBJECTIVES AND CONTROL PAGEREF _Toc515964589 \h 316.7.1 quality Standards PAGEREF _Toc515964590 \h 316.7.2 Project and Product Review AND ASSESSMENTS PAGEREF _Toc515964591 \h 326.7.3 Agency/Customer Satisfaction PAGEREF _Toc515964592 \h 326.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS PAGEREF _Toc515964593 \h 326.8 CONFIGURATION MANAGEMENT PAGEREF _Toc515964594 \h 336.8.1 Version Control PAGEREF _Toc515964595 \h 346.8.2 Project Repository (Project Library) PAGEREF _Toc515964596 \h 346.9 PROCUREMENT MANAGEMENT PLAN PAGEREF _Toc515964597 \h 347. 0 Project Close PAGEREF _Toc515964598 \h 357.1 Administrative Close PAGEREF _Toc515964599 \h 357.2 Contract Close PAGEREF _Toc515964600 \h 36AttachmentS PAGEREF _Toc515964601 \h 36Revision HistoryRevision NumberDateComment1.0May 23, 2018Draft 1.1June 5, 2018Submitted for Review1.0 Project Overview 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 sourcesSourceAmountAssociated restrictionsApproversLaws of 2019, Chapter 73, Section 7 (16)$967,000NONELegislationGovernor1.3 constraintsNumberDescription1Funding2Staff time3Unforeseen obstacles1.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/procurementNumberDescriptionType M,D,E1Existing permit data must migratem2pre-paid accounts must migratem3inspectors must have android or iphoned4contract approvalse1.5 ASSUMPTIONSNumberDescription1ANM stays in business and remains on statewide price agreements2RLD IT team is regularly available for technical discussions and project management3Project will be completed within defined timeline4Project scope will not change5Information 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 or if a hybrid approach where some Data is Migrated and some Data is Implemented is possible.6ANM 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.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.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 browserField Services Lightning App supports Android v4.4 or later, and iOS 9.3 or laterRLD understands the limitations that come with the Field Service Android App and the Field Service iOS AppThe 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 UsersPerson 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: 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 RisksRISKPROBABILITY& IMPACTMITIGATION PLANVendor abandonment (software development): If the contracted vendor were to abandon the project then the project would be halted or seriously delayed. L/HThe 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 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/MPayment 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/MRLD 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.1.6.2 Internal RisksRISKPROBABILITY& IMPACTMITIGATION PLANInadequate 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/HProject 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/HInclusion 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/LSince 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/HOur 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.2.0 Project Authority and Organizational Structure2.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. nameStake in ProjectOrganizationTitleRichard LuceroPermitting Front Desk SupervisorRLDCID Bureau ChiefJesus CarrascoManufactured Housing Department (MHD) supervisorRLDMHD Bureau ChiefClay BaileyLP GasRLDLP Gas Bureau ChiefRobert UnthankExecutive SponsorRLDSuperintendent2.2 Project Governance Structure2.2.1 Describe the organizational structure – Org Chart2.2.2 Describe the role and members of the project steering committeeExecutive 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 CHIEFAgency CIO/IT Lead – Michelle Langehennig, CIO, RLDProject Manager – Fabio Mir, Application Developer, RLD2.2.3 Organizational Boundaries, interfaces and responsibilitiesThe 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.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 ObjectivesNUMBEROBJECTIVE1Migrate current proprietary software code based Accela implementation to code based application that is configured and controlled by RLD. 2Maintain 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.3Maintain 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. 5Maintain 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 ObjectivesNumberDescriptionTechnical Objective 1Create online permitting application using industry-standard coding and best practices standards. Technical Objective 2Create robust data repository for the permitting application program following best practices standards. Technical Objective 3Create a very user-friendly public facing interface.Technical Objective 4Create an easy to use day-to-day operations interface.Technical Objective 5Create a comprehensive administration interface.Technical Objective 6Create a mobile interface for the inspectors.Technical Objective 7Create an easy way to create new permits or record types.Technical Objective 8Ensure the replacement programs has an unlimited upload document size.3.2 Project exclusionsNo exclusions3.3 Critical Success Factors NumberDescriptionQuality Metrics 1Measured by percentage of transactions initiated and processed through the online Permitting and Licensing portal.Quality Metrics 2Measured by number of requests for assistance and complaints as a percentage of total transactions successfully processed.4.0 Project Deliverables and methodology4.1 Project Management Life CyclePhaseSummary of PhaseKey DeliverablesPlanningAcquire the software and licensing to implement the permitting and inspection software for construction industries.Software licensingPlanningGather 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.ImplementationDevelop 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 DeliverablesThe 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.4.1.1.2 Project PlanDescription - Deliverable Acceptance Criteria – Completed Project PlanStandards for Content and Format – Microsoft Project PlanQuality Review – Reviewed by key stakeholders4.1.2 Deliverable Approval Authority DesignationsComplete 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 NumberDeliverableApprovers (Who can approve)Date ApprovedPRJ-DEL-001Project Management Plan (PMP)Martin RomeroJesus CarrascoMichelle LangehennigFabio MirPRJ-DEL-001Project Plan (PP)Martin RomeroJesus CarrascoMichelle LangehennigFabio Mir4.1.3 Deliverable Acceptance Procedure The following procedure will be used for the formal acceptance of all deliverables.Deliverables will be submitted by ANM to RLD Project Manager and project team for review. The RLD PM will distribute the deliverable to additional subject matter experts, as applicable, and coordinate feedback to ANM.ANM will incorporate review comments/suggestions. 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 PhaseSummary of PhaseKey DeliverablesPlanningInitial Business Analysis & KickoffAcquire the software and licensing to implement the permitting and inspection software for construction industries.PlanningProject ManagementGather 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.ImplementationSystem Requirements & Design DocumentationSystem ConfigurationSystem Development & DeploymentTrainingDevelop 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 StrategyTechnical Strategy for Configuration is listed in detail in the ANM Statement of Work document.4.2.2 Product and Product Development DeliverablesProduct 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 TypesDeliverable 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.4.2.2.2 Permitting ApplicationDescription - One Permit Type Active in Production Environment of Permitting ApplicationDeliverable 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 DocumentQuality Review – User Acceptance Criteria4.2.3 Deliverable Approval Authority DesignationsDeliverable NumberDeliverableApprovers (Who can approve)Date Approved1Permitting Application DesignMartin RomeroJesus CarrascoMichelle LangehennigFabio Mir2Permitting ApplicationMartin RomeroJesus CarrascoMichelle LangehennigFabio Mir4.2.4 Deliverable Acceptance ProcedureThe 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 Work5.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.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. 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.Deliverable 3 – Not Included in this Scope of Work – ANM will finalize the design for the 30 remaining permit types. 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).Deliverable 5 – Not Included in this Scope of Work – ANM will design the Compliance Application in Salesforce. 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).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 / ActivityAssociated DeliverablesEstimated BudgetPhase 1PlanningAcquire the software and licensing to implement the permitting and inspection software for construction industries.$413,000Phase 2PlanningGather 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,000Phase 3ImplementationDevelop 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,000TOTALS$967,0005.4 Project Team5.4.1 Project Team Organizational Structure See Section 2.2.15.4.2 Project Team Roles and ResponsibilitiesRoleResponsibilityNameFunctional AreaExecutive SponsorEnsure project funding. Approve any changes to project plan or scope. Communicate with Project Manager the status of project.Mike UnthankCabinet SecretaryBusiness OwnersPart of the business requirements gathering and verifying that the progress is headed in an acceptable direction.Martin RomeroJesus CarrascoClay BaileyAmanda RoybalRichard LuceroDivision DirectorsUser Acceptance TeamFormal acceptance of project deliverables.TBDCross-FunctionalOperations TeamTeam 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 testingTBDCross-FunctionalApplication Support TeamInternal IT Applications DevelopersChuck SlocterAmanda UriosteFabio MirApplications DevelopmentIT Project ManagementVendor TeamTeam of Vendors implementing SalesforceSalesforceANMCross-Functional, representing application development, project management and training5.5 STAFF PLANNING AND Resource ACQUISITION5.5.1 Project StaffResource Cost EstimateEstimated HoursAvailabilitySkill SetWork Product/DeliverableSalesforce$413,000Per ContractSalesforce Platform LicensingPer ContractANM$554,000Per ContractSalesforce Development, Project Management, TrainingPer Contract5.5.2 Non-Personnel resourcesResource Cost EstimateEstimated units/hoursAvailabilitySourceWork Product/DeliverableN/A5.6 PROJECT LOGISTICS5.6.1 Project Team TrainingResourceCost EstimateEstimated HoursAvailabilitySkill SetWork Product/DeliverableN/A6.0 Project Management and Controls6.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 StrategyRisks 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 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 IdentificationThe 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 ApproachAll 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 StrategyRisk 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 ApproachThe 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.6.1.6 ISSUE MANAGEMENT6.1.6.1 Internal Issue Escalation and Resolution ProcessRefer to above flowchart.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 AreaInclude –Yes/NoProject ManagementYesQuality ManagementYesTrainingYesRequirements ManagementYesOperating EnvironmentYesDevelopment EnvironmentYesSoftware DevelopmentYesSystem and Acceptance TestingYesData ManagementYesOperations OversightYesBusiness Process ImpactYes6.3 Scope Management Plan6.3.1 Change Control6.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:Estimated date by which change will be completed if approvedChange request numberHigh level assessment of the impact of the change (anticipated price impact, anticipated schedule impact), and consequential changes to the Scope of WorkRequested approvals from specified project team members. The Change Request form will include the following information:Date submittedChange categoryDescription of changeEvents 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 TrackingThe 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.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 MatrixCommunication TypeObjective of CommunicationMediumFrequencyAudienceOwnerDeliverableInitial Logistical Kickoff MeetingIntroduce the project team and the project. Review project objectives and management approach.- Conference CallOnce- Project TeamVendor Project Manager- Meeting Minutes- PMP- Issue tracking system & other documentation templates as neededBusiness Analysis & Project KickoffIn-depth review of business processes & needs across all stakeholders. Formal project kickoff across full project team.- Face to FaceOnce- Project Sponsor- Project Team- StakeholdersVendor Project Manager- Meeting Minutes- Baseline project schedule- Updated PMPProject Team MeetingsReview status of the project with the team.- Face to Face- Conference CallBi-Weekly- Project TeamProject Managers- Meeting Minutes- Updated Project Schedule & issue/risk logIT Project ReportsReport the status of the project including activities, progress, costs and issues.- EmailBi-Weekly Monthly (ESC Report)- Business Owner- IT LeadershipIT Project Manager- Project Status ReportESC Project Status ReportsReport the status of the project including activities, progress, costs and issues.Conference call and emailMonthly - Project Sponsor- Project TeamBusiness Project Manager- Project Status Report- Project ScheduleDoIT Monthly Status ReportsReport the status of the project, including progress, cost, performance to budget and risk.EmailMonthly- DoIT- PCC - General PublicIT Project ManagerMonthly ReportExternal stakeholder updatesReport progress and solicit input from stakeholders as project proceedsConference call or emailMonthlyExternal StakeholdersBusiness ownerMeeting Minutes6.5.2 Status MeetingsWeekly 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 ReportsThe following status reports will be delivered throughout the life of the project:Contractor weekly status report to RLD-ITMonthly Status Report to Business Owners provided by PM.IV&V Reports to Business Owners, CIO, & EPMOMonthly report to DoITAd-hoc reports as necessary6.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 BaselinesProject AreaCategoryMeasureProject ManagementTask performance On ScheduleQualityErrors in Data ModelingErrors by functional areaTesting (Data Warehouse)Performance and QualityAccepted/Not AcceptedImplementationQuality DataA final data feed from the Subject Matter Expert (SME) that is accurate and complete.6.6.2 Metrics LibraryA 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 StandardsEach 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 StandardTracking Tool or Measure1Project phase is completed by the established finish date.Project ScheduleProject Status2Project is completed within budget.Project CharterProject Status3Monthly project reviews show contractors deliver requirements specified in the contract by due dates.Vendor ContractCustomer ApprovalsProject Schedule4Project issues are resolved and documented within specified time limits, or extensions are justified.Issue Tracking5Project will be completed based on the original project scope and approved scope changes.Project CharterProject PlanChange Request(s)6.7.2 Project and Product Review AND ASSESSMENTSReview TypeQuality StandardToolsReviewerReportsPeer ReviewsPer deliverableChecklists anddeliverableacceptance criteriaTeammembersEdited /commenteddeliverableTestingSystem andAcceptance TestCyclesTest scripts andCases.Test Plans.Automated testScripts.TeammembersTest ResultsInternal AuditsCloseout tasksProjectdocumentation andcommunicationreview.RLD PM , ANM/Salesforce Project TeamLessons Learned,Phase CloseoutReports6.7.3 Agency/Customer SatisfactionAreas of feedbackWhenHow OftenAgency awarenessMeeting to go over the status of the projectWeeklyQuality of communicationsContractor is always available to call or emailsWeeklyManages project tasksHas been keeping a running log of all the items to ensure RLD questions and concerns are addressedWeeklyProductive MeetingsMeetings held weekly and RLD updated with system configuration assignmentsWeekly6.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.DeliverableFinal Approval ProcessCustomer Acceptance CriteriaScoping SessionSignature approval by Business OwnersReceipt of Scope of Work DocumentationIV&VSignature approval by Business OwnersReceipt of Initial and Final Reports with 4 Interim Reports.SoftwareSignature approval by Business OwnersPurchase of SoftwarePlanning and InstallationSignature approval by Business OwnersLoaded software onto landscape and receive discovery workshop scoping documentDesign DocumentSignature approval by Business OwnersReceipt of Business System Design DocumentsConfiguration and BuildingSignature approval by Business OwnersDocuments reviewed and approved by designated RLD representatives. TestingSignature approval by Business OwnersTest results are reviewed and approve by designated RLD representativesTrainingSignature approval by Business OwnersTraining documents produced in accordance with curriculum outlined in the Training Plan. Document reviewed and approved by designated RLD representative. Identified Training Sessions completed.Go-LiveSignature approval by Business OwnersAll defined acceptance forms signed by designated RLD representative. Project ManagementSignature approval by Business OwnersAll defined acceptance forms signed by designated RLD representative. Cloud Hosting and Warm StorageSignature approval by Business OwnersExecuted Contract and Maintenance Agreement6.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. 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 ControlA 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.7. 0 Project Close7.1 Administrative CloseAdministrative 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.7.2 Contract CloseContract close for this project will comply with all State and RLD procedures for contract close.AttachmentSNone. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download