POLARIS Project Management Plan Release 2

POLARIS
Washington Department of Licensing

Enterprise Business and Professional Licensing and Regulatory System
Project Management Plan Release 2

Project Management Plan POLARIS PMP
Document Control Information
Document Information
Document Identification POLARIS PMP
Document Name Project Management Plan Release 2
Project Name POLARIS
Client Washington Department of Licensing

Document Author Chris Little
Document Version 1.0
Document Status Release
Date Released 1/15/2020
Document Edit History
Version Date Additions/Modifications Prepared/Revised by

1.0 1/15/2020 Original Draft Chris Little
1.1 1/24/2020 Final Draft Chris Little
Document Review/Approval History
Comments / Approval
Date Name Organization/Title
Status
1/15/2020 John Bosso Deloitte / PM Approved for Release
1/22/2020 Megan Pilon DOL/PM Several modifications as well as
some questions/comments.
1/23/2020 Megan Pilon DOL PM Accepted Deloitte changes, made
a couple of
comments/suggestions/question.
1/24/20 Megan Pilon DOL PM Approved.
2/5/2020 Page 1 of 50 POLARIS

POLARIS Project Management Plan Release 2.docx
Table of Contents
1 Purpose....................................................................................................................................4
2 Project Goals and Objectives ............................................................................................5
3 Scope Management Plan ....................................................................................................7
Scope Management ........................................................................ 7
3.1.1 Define Scope ...........................................................................................................7
Scope and Schedule ........................................................................................................................ 7
3.1.2 Validate Scope.........................................................................................................7
3.1.3 Control Scope ..........................................................................................................8
Design and Implementation Principals .................................................. 8
Governance Structure for System Design Decisions ................................. 9
Information, Processes, and Tools to Manage Requirements ...................... 9
Approach to Tracing Requirements Compliance ...................................... 9
Change Control Process, Roles, and Responsibilities ............................. 10
3.6.1 Formal Change Control Process ........................................................................10
Initiating a Change. ........................................................................................................................ 10
Handling a Change Request......................................................................................................... 11
Tools ........................................................................................ 12
Roles and Responsibilities .............................................................. 12
Handling a Change Request that DOL has decided to pursue ................................................ 13
Resolution........................................................................................................................................ 13
3.8.2 Tracking Change Orders......................................................................................13
3.8.3 DOL Standard Change Request Form ..............................................................13
Monitoring Progress Against Scope ................................................... 13
3.9.1 Hybrid Agile Model ................................................................................................13
4 Resource Management Plan ............................................................................................17
Project Work Streams Roles and Responsibilities .................................. 17
Contractor Resources.................................................................... 19
DOL Resources ........................................................................... 21
Contractor Presence On-Site ........................................................... 25
Contractor Staffing Approach ........................................................... 25
Contractor Staff On-boarding ........................................................... 25
Approach to Coordinate Vacation and Holiday Schedules ........................ 26
Monitoring Staffing Levels Versus Project Requirements .......................... 26
5 Schedule Management ......................................................................................................28
Key Schedule Management Concepts ................................................ 28
Approach to Schedule Management .................................................. 28
5.2.1 Develop and Baseline...........................................................................................28
5.2.2 Track Progress and Maintain ..............................................................................29
5.2.3 Refine and Revise .................................................................................................29
5.2.4 Rebaseline (as approved)....................................................................................30
Frequency of Updates ................................................................... 30

Level of Granularity of Tasks ........................................................... 30

Distribution, Storage, and Access to the Plan ....................................... 30
Roles and Responsibilities for Schedule Updates................................... 30
Approach to Tracking Progress versus Plan ......................................... 31
6 Communication Management Plan ................................................................................32
Communication Approach ............................................................... 32
Status Report .............................................................................. 32
6.2.1 Weekly Status Report ...........................................................................................32
6.2.2 Monthly Status Report ..........................................................................................32
Stakeholders and Communication Needs ............................................ 32
7 Quality Management Plan .................................................................................................35
Deliverable Review Process ............................................................ 35
7.1.1 Overview .................................................................................................................35
7.1.2 Define Deliverable Expectations .........................................................................35
7.1.3 Draft Deliverable ....................................................................................................35
7.1.4 Review Deliverable ...............................................................................................35
7.1.5 Sign-off Deliverable...............................................................................................35
7.1.6 Deliverable Reviews .............................................................................................36
Work Product Review Process ......................................................... 37
Roles and Responsibilities .............................................................. 37
8 Risk and Issue Management Plan ..................................................................................39
Risk Management Process ............................................................. 39
8.1.1 Risk Management Process ..................................................................................39
8.1.2 Risk Severity Scoring Matrix ...............................................................................42
8.1.3 Risk Monitoring ......................................................................................................42
8.1.4 Risk Meetings ........................................................................................................43
Issue Management Process ............................................................ 43
8.2.1 Issue Monitoring ....................................................................................................46
8.2.2 Issue Management Meetings ..............................................................................46
Risk/Issue Types ......................................................................... 47
9 Project Organization ..........................................................................................................48
10 Deliverables Log..................................................................................................................49

1 Purpose
The Project Management Plan (PMP) documents the structure, processes, and resources that will be
used to execute the Professional Online Licensing and Regulatory Information System (POLARIS)
Project for the Washington State Department of Licensing (DOL). These processes and resources will be
utilized to undertake the project work and create deliverables that meet the POLARIS Project contractual
requirements. The PMP covers the organization, approach and timeline, controls, schedule and resource
management, tools, quality management and communication plans. This will provide the foundation to
achieve project goals and communicate how the program will be managed.
The PMP is approved by the project leadership during the early stages of the project and is maintained
throughout the life of the project. It is a living document that is kept up-to-date and should be considered
the primary source for information about the projects’ organization, stakeholder engagement in activities,
and management processes, tools, and terminology. The Deloitte and DOL project managers will review
the PMP as required throughout the project. A formal review will be conducted at the beginning of
Release 2 update it and do a second formal release of the deliverable.
Once the PMP has been approved, the management processes described herein will be the basis for
training the teams in project processes. This training will be included in the team member onboarding
procedures so that new team members are properly trained.
Upon approval, this plan will be baselined and archived in the DOL POLARIS SharePoint Repository.
Except for minor wording changes or changes to the organization charts and/or resource assignments in
the Governance section, this plan will not be changed without an approved Change Request. The Deloitte
Project Management staff are responsible for updating this document, as required, when resource
assignments change or there is an approved Change Request. The revised PMP will be reviewed and
approved by the DOL EPMO Director prior to being updated in the Document Management System.
Note: this deliverable is an update of the original PMP approved in Release 1.

2 Project Goals and Objectives

The Project Charter lays out the POLARIS Goals and Objectives. They are repeated here for context
supporting the policies, practices and procedures developed for the PMP.
The overall project Goal Statement is:
To procure, configure and implement a commercial off-the-shelf solution for DOL’s Business and
Professional licensing programs that improve the business climate by facilitating easier access for
consumers and licensees, and provides DOL staff and licensees with an easy to use, cost-
effective, reliable and sustainable system, fully implemented by summer 2020.
The specific Project Goals from the Charter are:
1. Improve and expand online access to the public and licensees for licensing, account
maintenance, searching, and filing complaints
2. Integrate licensing, compliance, and financial management processes
3. Gain efficiencies through streamlining processes, implementing industry best practices,
modernizing technology, and automating operations processes
4. Increase system reliability, sustainability, and adaptability
5. Improve data access and ability to electronically receive and provide data to other
systems
6. Retain or improve standard for customer experience
The Charter goes on to list specific Project Objectives:

DOL licenses approximately 275,000 individuals and businesses. A new solution will improve the
business climate by providing easier access for consumers and a more reliable solution for
businesses. Specific impacts include:
Business and Professional Licensees:
 Improve time to license for those programs that do not currently have online access for
licensing applications and renewals. Solution will enable at least 14 business types and
21 professions to apply and renew online.
 Provide ability for low-risk professions to print their own license. It is anticipated that at
least 16 professions and 13 business types could print licenses.
 Increase payment options available to licensees.
 Provide ability for licensee to track status of application and renewals.
Consumers:
 Increase consumer access to data with more online options.
 Provide consumers (or public) the ability to file complaints online.
 Improve public safety through more accurate and timely data related to complaint
notifications and agency follow-up.

Business Partners:
 Provide online interaction for third parties so data can be submitted in real time.
 Increase ability to support open data using modern COTS interface and data exchange
capabilities.

3 Scope Management Plan

Scope Management defines the process and procedures for confirming, verifying, and controlling scope.
A clearly defined scope promotes the stability required to the goals of a project or program. By adhering
to this process, the projects within the program will improve their control of project scope, leading towards
project completion on time and on budget and informing stakeholders of key changes. There are two
aspects of project scope that must be controlled:
 Scope of the solution—this is the set of features and requirements that have been identified and
will, in conjunction with people changes, generate the business benefits that justify the project
and program.
 Scope of work—this is the set of activities and deliverables that the team will do to deliver the
solution.
Scope Management
Project scope of the solution is defined in the Requirements, Appendix B of Contract K6512. The scope
of the solution is being further detailed in User Stories developed in the Discovery and Design stages of
the project.
The scope of work is defined in the Scope of Work Appendix C to Contract K6512. The following sections
describe the overall concepts to Scope Management, as well as the major scope activities that occur after
project kick-off follow the scope management lifecycle which includes define, validate, and control scope
throughout the project lifecycle.
3.1.1 Define Scope
Scope confirmation is completed during the early stages of each release and is a joint activity that is
performed by the Deloitte and DOL Team Leads, PMO Staff, and Project Managers. The scope of the
solution differs from the scope of the work. The scope of the work describes the tasks and deliverables
needed to achieve the scope of the solution while the scope of the solution involves the overall features
and components that will produce the defined business benefits.
The Requirements will be loaded into a Requirements Traceability Matrix (RTM) in this case implemented
in the POLARIS SharePoint Site. The RTM will include the requirements, associated business rules, and
user stories (Note: Test scenarios/scripts are included in Azure/TFS as part of the user story.)
Scope and Schedule
The Project Schedule is an important companion document to the scope of work in that it documents:
 The major activities and their timing that the team will perform
 Accountability (by team and/or organization) for performing those activities
 External dependencies and their timings, and the team and/or organization that is responsible for
their completion
Moreover, once the Project Schedule is re-baselined for release 2, it is subject to change control process.
3.1.2 Validate Scope
Once the scope is defined and baselined, both DOL and Deloitte project managers are responsible to
validate scope throughout the project lifecycle. To validate scope, they will confirm:
 the work being performed remains in scope, and
 Addresses the boundaries of the scope of the solution via contract requirements, design
definition, user stories, and test cases.

The project managers will compare major solution definition deliverables with predecessor deliverables
(e.g., requirements to charter, business rules to requirement, user stories to requirements/business rules,
design to user stories, etc.) to confirm that the original scope is addressed, and additional scope elements
have not been added. Refinements to scope and decisions regarding scope will be documented in the
RTM and Decision Log. The Deloitte and DOL PMs will work to confirm that the refinements and
decisions do not reflect an expansion of scope and will work with staff to mandate that scope issues are
addressed by the team.
The PM will also validate the scope of the project work against the baselined Schedule. This validation
activity confirms that:
 Resources are working on their assigned activities and tasks
 External teams are working towards meeting the deadlines established in the project Work Plan
3.1.3 Control Scope
The objective of scope control is to manage activities that alter one or more aspects of the project scope,
including schedule, deliverables, functionality, or budget. The scope items described in this section are
baselined after approval and will not be changed without an approved Change Request (see the Change
Control Management section).
In addition, as solution deliverables are approved (such as User Stories demonstrated to Product Owner),
they also fall under the change request process. See flow below.
3.1.4 Reporting on Scope

Scope management is key to successful project delivery, therefore, scope is a key reporting metric in the
monthly status report. As change requests are submitted, project management will monitor impact on
budget and schedule. Due to not changing go-live date from June 29, any change requests that would
delay June 29 delivery date would qualify as making scope red. Most change requests will impact
budget, POLARIS has a very small budget contingency to work with. Therefore, scope change requests
will be reported based on how much contingency is remaining. If 50% to 75% of contingency budget is
used by either approved or requested change requests, scope will be reported as yellow. If more than
75% of contingency budget is used by approved plus requested change requests, then scope will be red.
Design and Implementation Principals

In order to address the goals and objectives of the project a number of principals emerge for how scope
should be defined and managed. These principals are:

 Standardize processes, procedures and communications to the degree practical across license
programs and types.
 Utilize the configurable components delivered in the eLicensing framework rather than custom
developing new functionality where possible.
 Execute quickly to meet contractual obligations while allowing for two incremental releases of the
application.
Governance Structure for System Design Decisions

Managing decisions includes identifying, documenting, prioritizing, assigning, and tracking the results of
decisions throughout the phases of the project. Decision are tracked in the Decision Log in SharePoint.
Any project team member upon recognizing that a decision is required can log a decision in the
SharePoint Log and assign the decision to themselves or another team member. The decision log will
be monitored by the Product Owner or designee and the Functional Lead to confirm that decisions are
being closed in a timely manner.
Where a decision needs attention it will be brought to a regularly scheduled check-in meeting with project
leadership where the topic will be discussed, direction developed and action items assigned to drive the
decision to closure.
Once the decision is made, the Decision Log will be updated with the final determination and the decision
closed. . During the decision making process, system impact is assessed, and after a decision has
been made, the decision owner is responsible for ensuring a user story is created or updated.
Information, Processes, and Tools to Manage Requirements

The primary tools for managing requirements for the purpose of managing the development process will
be POLARIS SharePoint Requirements Traceability Matrix and TFS (https://dev.azure.com/DOL-
POLARIS). Requirements traceability will be managed in SharePoint where the requirements will be
mapped against business rules. The requirements in SharePoint will be mapped to user stories that are
housed in TFS. User stories will be split into multiple swim lanes and/or boards by project team, such as:
• Functional Configuration
• Integration
• Data Conversion
Additional swim lanes can be added throughout the project as the teams continue to self-organize.
User stories will contain Definitions of Done and Acceptance Criteria providing sufficient details for
developers to complete the user stories and testers to validate it is complete. Acceptance Criteria may
reference additional documentation such as API specifications and design documents as needed.
As user stories progress through the development they will go through several statuses until the reach the
final status of ”closed.” The Closed status indicates that the story has been completed and all
requirements documented in the story have been validated, and no further work is required on that story
and it is ready for System Integration Testing.
Approach to Tracing Requirements Compliance

The original requirements for the project and detailed business rules are maintained by DOL
Requirements Manager in a Requirements Traceability Matrix (RTM) on the POLARIS SharePoint site.
The Deloitte team will work in close to collaboration with the DOL Requirements Manager to map the
requirements in the RTM to user stories in TFS and keep this mapping updated. User stories will be

mapped to the original requirements as the last step of the user story grooming process. Deloitte will
work with RTM manager to map the test scripts to the RTM.
The DOL Requirements Manager will be responsible for maintaining the mapping of requirement-to-user-
story linking in the RTM. The actual user stories will be housed and managed in TFS. The RTM will
contain a reference to the user story ID to allow tracking of user stories to requirements.
The test script to-user-story mapping is in TFS.
Change Control Process, Roles, and Responsibilities

A standard and consistent project change management process will be used for requesting and
managing changes to deliverables and work products for the POLARIS project. The project scope
management process will be structured to facilitate communication among stakeholders about requested
changes to scope, provide a common process for resolving scope change requests and addressing
reported problems, and reduce the uncertainty around the existence, state, and outcome of a change that
has been requested.
A change request is a change to anything that has been baselined (such as the project schedule) or
approved (such as key deliverables or approved user stories). See section 3.1.3 of when a change
request would be submitted regarding the solution.
3.6.1 Formal Change Control Process

Any stakeholder can submit a change request. All change requests will be proposed and responded to in
writing.
• Any change request should be memorialized in a Change Request Form
• Change Requests involving changes in price, changes to contractual Requirements, changes to
the Statement of Work or the baseline Project Schedule must be approved and signed by the
appropriate DOL signing authority and either the Deloitte Executive Advisor, Deloitte Project
Manager, or Deloitte Project Director.
Initiating a Change.
The scope management process begins with identifying a potential change. Any team member can raise
a potential change, which is then raised to the DOL Project Manager. The DOL Project Manager will
work with the team member, Deloitte Project Manager, and other participants to document the Change
Request using the Change Request form. It will be first reviewed to ensure it is not a duplicate of an
existing Change Request, and checked for validity and adequate information to begin analysis. All
Change Requests, their statuses, and any associated documentation will be maintained in POLARIS
SharePoint log.
Change Request status will be maintained according to the following status definitions:
Change Request Status Status Definition

New A Change Request that is currently under review.
Assessing Impact A Change Request that is currently being worked
on.
Pending Decision A Change Request that is awaiting review after
the impact has been determined.

Change Request Status Status Definition

Complete A Change Request that has been completed,
rejected, or is a duplicate.
Handling a Change Request
The DOL Project Manager will then facilitate an analysis of the Change Request to determine its impact
to scope, cost, schedule, and quality. Impact analysis may include some or all of the following items:
 Baselines affected
 Formal Configurable Items affected, such as a specific components of system functionality or
infrastructure design
 Description of the change and a discussion of how it would impact the various components and
processes of the POLARIS project
 New or modified requirements
 Evaluation of risk items associated with the Change Request
 Effort analysis (including tasks, resources, durations, and their impact to the overall project
schedule)
 Dependencies and/or conflicts
 Compliance with existing standards
 Impact on other pending and scheduled changes
 Cost impact
 Impact if Change Request is not implemented
 Alternatives to the proposed Change Request
 Final recommendations
Change Request analysis will result in establishing a criticality measure. Criticality characterizes the
relative urgency of the change with respect to the POLARIS project. The determining criteria shown in the
following table identify how quickly a change must be incorporated in order to achieve success in the
current phase of the project:
Change Request Criticality Definition

Criticality
Immediate Action Imperative to the success of the project phase, and
likewise, may have a detrimental impact to the project if
not addressed promptly. Work stoppage or severe impact
on scope, cost, schedule, or quality is imminent or has
occurred; solution needed immediately.
To Be Scheduled Has the potential to impact the success of the project but
is not an immediate help or hindrance. Impact on scope,
cost, schedule, or quality is expected: work-around has
been identified; solution is needed.
Desirable Needs to be addressed if time and budget permit – will be
managed as resources are available.
Change Requests are reviewed by the DOL and Deloitte Project Managers and Project Team. The DOL
Project Manager will submit to the Enterprise Program Management Office Director, Project Sponsor,

Steering Committee, and/or Executive Sponsor the completed Change Request Form and associated
impact analysis with the Project Managers’ and Project Team’s recommendations for approval,
disapproval, or escalation.
All approved Change Requests must be signed off by the appropriate level as described below.
 The Enterprise Project Management Office Director and Project Sponsor can sign for a change
that has no impact to a project payment milestone, can be addressed within the current allocated
budget and fiscal year (including contingency), and has only a minor impact on functionality with
no impact on the Agency’s ability to deliver services to constituents.
 All other Change Requests will be raised to the Business Sponsor and/or Executive Sponsor for
review and approval.
 Where a Change Request is denied, there may be alternative actions (e.g., implement a
workaround for a functional gap) to be executed. If so, these efforts will be initiated and managed.
Once the efforts are initiated and managed, the Change Request can be closed.
 Where a Change Request is approved, there may be many activities required such as project
budget/schedule/resource changes and task execution. Once changes are implemented, and
reviewed, the Change Request can be closed.
The DOL Project Manager will update the in-progress Change Requests for any status changes. The
DOL Project Manager will send notification of the change status to the POLARIS Project team members
and stakeholders affected by the decision.
Approved Change Requests will then be submitted to Deloitte using the processes identified in the
contract.
Tools
The tools used to support the scope management process include:
 Requirements Traceability Matrix (RTM)
 Team Foundation Server (TFS)
 Change Request Log
 Change Request Document
Roles and Responsibilities

Key roles and responsibilities for this activity are described below.
Role Change Management Responsibility

POLARIS Project Team  Identify and record potential scope changes in log*
member
DOL Project Manager,  Analyze change and evaluate alternatives
Deloitte Project Manager  Prepare change documentation
 Maintain the Change Log
 Present changes for consideration
 Update project documentation, plan and execution to reflect
approved changes
 Ensure adherence to change process
Enterprise Program  Approve or deny low-impact Change Requests
Management Office Director
Project Sponsor  Approve or deny low-impact Change Requests
Steering Committee  Approve or deny high-impact Change Requests

Role Change Management Responsibility

Executive Sponsor  Approve or deny high-impact Change Requests that the Steering
Committee is unable to make a determination on.
QA Consultant  Monitor compliance with state-defined scope management best
practices
Handling a Change Request that DOL has decided to pursue

Upon receiving a Change Order Request the receiving party may accept and sign documents as
proposed which will then become Final Change Order, or, alternatively, may jointly develop and negotiate
the terms of the Final Change Order.
Resolution
If the Parties are unable to agree to the terms for the Change Order, either party will escalate the Change
Order Request through the Issue Resolution Process defined in the contract.
3.8.2 Tracking Change Orders.
All Final Change Orders will be tracked by Deloitte and Deloitte shall provide DOL with a monthly status
report on performance of Final Change Orders within ten (10) business days of the beginning of each
month.
3.8.3 DOL Standard Change Request Form
The change request form template is located here.
The change log is located here.
Monitoring Progress Against Scope

Functionality will be implemented primarily as user stories. Points or hours will be assigned to stories,
stories will be monitored through burndown and velocity models.
3.9.1 Hybrid Agile and Kanban Model
Release 2 has the following teams/work streams for configuration and development:
 Data Conversion
 Decommissioning Legacy Systems
 Integration
 5 Functional teams:
o Real Estate, Home Inspectors, and User Experience
o Cosmo, Tattoo, Compliance, and BLS
o Public Protection, Combative Sports, Auction/Auctioneers, and Court Reporters
o Driver Training Schools, CDL (schools, examiners, instructors and courses), and
Motorcycles (schools, instructors, courses, and examiners)
o Financial
The functional teams will have a relatively large number of user stories defined at a relatively granular
level. These stories are expected to be addressed through configuration of the application rather than

classic development work. As a result, the completion of each individual story is a relatively low level of
effort.
The Functional Team, which includes the financial work stream, will use a Kanban approach in Release
2. This means that user stories will be developed during the discovery/design phase and will be groomed
and approved by the DOL Product Owner. Once a user story is approved by the product owner, it is ready
for development. The development team will then pull from the user stories that are ready where it is
then developed, unit tested, functionally tested, and demonstrated to a DOL SME. If the DOL SME
approves the user story, it is then set to “Ready for PO Demo” in TFS and is demonstrated as part of a
complete flow when flow is complete to the DOL Product Owner or delegate. If the DOL Product Owner
approves the user story, it is marked “Closed,” which means it is ready for System Integration Testing. If
the DOL Product Owner does not approve the user story, it is marked “Dev Rework” and the defects are
remediated by the development team and re-enters the workflow at the DOL SME Demo task.
The Data Team and the Integration Team will follow the hybrid agile approach similar to what was used in
Release 1. All teams will share the same states and statuses in TFS. The primary difference is that the
Data and Integration Teams will structure their work in Sprints and not on the rolling basis that is used by
the Functional Team.
All user stories will need to be mapped to a requirement – Deloitte will not work any item in TFS that is not
mapped to a requirement.
Below is an overview of the user story approval process – from initial draft through DOL Product Owner
approval and closure.


The user stories will be pointed for the Data and Integration Teams prior to the start of the sprint. For the
Functional Team, the level of effort in hours will be added to the user story prior to the DOL Product
Owner approval. Data will be reported at least weekly on:
 Target Points/Hours in the sprint or development period
 Number of Points/Hours in Development
 Number of Points/Hours passed quality assurance
 Number of Points/Hours closed (per Product Owner demo approval)
For those teams using Sprints, as the sprint is completed the total number of points or hours passed and
the number of points or hours deferred to a future sprint will also be reported.
The user stories will be uploaded to Microsoft TFS and grouped by sprint (for Data and Integration
Teams) or by “Ready for Development.” The stories will then be tracked through a set of statuses. The
statuses are:
% Complete for
Step User Story Status Tracking
Purposes
1 New 0
2 Analysis and Design
3 Ready for Dev
4 Dev In progress
5 Dev Rework
6 Dev Complete
7 Ready for Testing
8 Testing in Progress
9 Ready for Demo
10 SME Approved 95
11 Closed 100
As user stories move through the development and validation process their status and percent complete
will be updated in TFS so that reports can be created on the progress within the sprint and against the
overall backlog
Metrics: Velocity will be determined by planned velocity vs actual velocity. DOL and Deloitte will develop
the reporting format based on the metrics above.

4 Resource Management Plan
The Resource Management Plan outlines how the project work is organized around teams of resources
and then goes on to summarize the resources and processes required to execute on the project on both
the Deloitte and DOL side.
The objectives of the plan are to:
1. Define the resource numbers, roles and requirements for the core project team.
2. Define the resource numbers, roles and requirements for DOL and other stakeholder participation
beyond the core team.
3. Identify the approach to placing and replacing key and non-key team members.
4. Identify the approach to coordinating holiday and vacation schedules.
5. Describe the monitoring of staffing levels versus project requirements.
Project Work Streams Roles and Responsibilities

The table below outlines the project work streams with the high-level responsibilities.
Function or Primary
## Description
Activity Responsibility
1 Project Provides project management and oversight of the Joint Activities
Management project, managing the project teams, monitoring and
managing scope and schedule and reporting status and
progress
2 Product Ownership Managing the compilation of user stories, configuration DOL
data and other design components against the
requirements of DOL. Providing oversight on the
development to confirm that the project is being
implemented in accordance with the specifications (user
stories)
Making or managing the making of decisions impacting
the design and implementation of the solution
3 Functional / This work stream focuses on implementing business Joint activities Deloitte
Configuration requirements related to the licensing, enforcement, and
financial processes through configuring the eLicensing
solution.
DOL to provide User Story acceptance criteria, demo
reviews and approvals. Deloitte responsible for
configuration and development.
5 Integration This work stream implements integrations to other Joint Activities
systems as specified in the scope of the project Deloitte implements new
integrations
DOL executes development
on legacy systems and
coordinates and manages
integration partners
7 Data The data is extracted from the legacy systems and is Joint Activities
Conversion/Cleanin placed into an intermediate staging area managed by DOL Data cleaning
g DOL. DOL and Deloitte will work together to map the DOL – Source to Staging

Function or Primary
## Description
Activity Responsibility
data from the staging area to the target Salesforce Deloitte - Staging to Target
structure. The data in the data staging environment gets
transformed to match the POLARIS data model and then
the Deloitte team will load that transformed data into the
application
Data cleaning focuses on achieving required level of

quality of data and bringing the cleaned data into the data
staging environment by DOL.
8 Organizational This work stream includes activities related to DOL
Change communication with internal and external stakeholders, as
Management well as training staff that will be the users of the system
(OCM)
9 Training This work stream includes the creation of training plans, Joint Activities
training materials and delivery of training. Deloitte - Training
Development and Train the
Trainer and technical
training
DOL – Support Training
Development and End User
Training
10 System Integration Validating operation of solution works as designed and in Deloitte
Testing alignment with requirements. SIT will occur once a whole
process flow is complete. For Release 2 – DOL
resources to participate in
SIT.
11 User Acceptance Validating operation of solution works as designed and in DOL
Testing alignment with requirements. UAT will include data,
permissions, and role validations.
12 Environment Implementation operations and management of the Joint Activities
Management POLARIS system environments DOL – Owns relationship
and licensing with Salesforce
and BasicGov
Deloitte – Day to day
operations, monitoring,
maintenance and
configuration of
environments
13 Cutover Activities associated with planning and executing the Joint Activities
activities associated with moving the application to DOL – Setup and operate
production including readiness activities, preparing the command center, Staff
production environment moving to production and then support team, undertake
providing immediate post go-live support (hypercare) cutover activities per cutover
plan; OCM, Stakeholder
communications, web site
and legacy system changes
Deloitte – Develop cutover
plan, manage cutover and
go-live processes, execute
production application,
configuration and conversion
load, Hypercare support

While the primary responsibility lies with the party specified in the table above, their ability to complete
their activities significantly depends on the other party participating actively and providing necessary
inputs / decisions. For example, Configuration work stream depends heavily on inputs and timely
approvals from DOL, while the OCM work stream depends on the training materials and train-the-trainer
session delivered by Deloitte.
Contractor Resources
Deloitte is providing a range of resource to undertake the project work. The resource model for the team
is presented in the table below.
Work will be done in a range of locations. Some resources will work largely or exclusively remotely while
the core solution and project management teams will largely be onsite. Where project requirements
allow, staff that live remote to the project site will use a model where they are onsite 3 to 4 days a week
and work from their home location 1 or 2 days per week. Where project needs dictate, staff will be onsite
5 days per week. Occasionally, some portion of the largely onsite project team may work remotely some
weeks.
The Deloitte staffing model is as follows:
## Resource Role Skills No Logistics

1 Project Director Oversight of the project, Issue Statewide licensing 1 Part time
resolution escalation Project and program
management
2 Executive Oversight of the project, Issue Statewide licensing 1 Part time
Advisor resolution escalation Project and program
management
3 Project Manager Day to day management of the Project and program 1 Largely onsite
project management
Conformance of solution to Licensing experience
requirements Team leadership
Scope management
4 Deputy Project Day to day management of the Project management experience 1 Largely onsite
Manager project Licensing experience
Oversight of solution development Solution leadership
Scope management
Requirements management
5 PMO Analyst Day to day project management Project management experience 1 Largely onsite
operations
6 Solution Leads solution design Statewide licensing 1 Largely onsite
Architect Leads business and functional Significant experience with
design work Deloitte solution
Oversight of configuration and Team leadership
development Requirements management
Scope and requirements System design
management
7 Configuration Takes requirements from business / Salesforce configuration 1 Largely onsite
Lead functional team and coordinates management experience
implementation of configuration Team leadership experience


and other components with remote
development teams
Coordinates environment
management activities
8 User Experience Oversees design and configuration Enterprise system user 1 Part time role as
Lead activities to monitor and enforce experience needed
sound user experience principals
Lease with DOL User Experience
staff
9 Functional Lead Leads the business and functional Salesforce experience 1 Largely onsite
team in the interpretation of Business requirements analysis
requirements and development of
configuration design
Works hand in hand with testing
lead to plan and execute SIT
10 Financial Track Primary resource to work with Salesforce experience 1 Largely onsite
Lead DOL Finance and accounting team Business requirements analysis
to capture required functionality
and configuration for
implementation
Primary testing responsibilities for
finance component in SIT
11 Business & Work with DOL SMEs and Salesforce experience 3-5 Largely onsite
Functional business analysts to interpret Business requirements analysis
Analysts requirements, capture configuration
for implementation
12 Technical Leads initial technical design Salesforce based technical 1 Largely remote
Architect activities and provides oversight architecture role
throughout project of technical Experience with Deloitte
activities licensing solution
13 Integration Lead Works with DOL staff to refine State systems integration 1 Largely onsite in
requirements, document and design MuleSoft based integration early stages of the
integrations. project. May
Oversees implementation of the move to a largely
MuleSoft integration routines remote role once
design is finalized
14 Integration Develop, primarily using MuleSoft MuleSoft integration 1 -3 Remote
Developers the integration routines required to experience
support interfaces
15 Data Conversion 1 Largely Onsite
Lead
16 Data Conversion Develop and execute data Data development 1-2 Primarily remote
Analyst migration routines to move data MuleSoft development
from Staging to production Conversion experience
Perform data analysis and
validation
Generate conversion statistical
reports
17 Configuration Undertake configuration of the Salesforce configuration 1 Remote
Analysts Salesforce and BasicGov
components of the application


18 Portal Undertake configuration and Salesforce configuration 1 Remote
Developers development of the front-end portal Portal development
19 UI Designer Under direction of the UX Lead Web user interface design 1 Remote
undertake design activities to Salesforce experience
support the user interface
(especially on the portal
components)
20 Testing Lead Develops test plans and manages Salesforce testing experience 1 Largely Onsite
the execution of SIT during SIT
21 Testing Analysts Unit testing and SIT testing System testing experience 2-5 Remote
Test scenario development
22 Training Lead Lead development of training plan Experienced technical trainer 1 Staffed during
and training materials. Deliver Experienced training materials training activities
train the trainer training developer Largely onsite
Training management
experience
23 Training Develop training materials Technical training materials TBD TBD depending
Analysts development experience on documentation
update needs
DOL Resources
The Department of Licensing (DOL) has assembled a project team to execute on the delivery of
POLARIS alongside Deloitte. The following table outlines the key roles that are required to deliver the
project. DOL may choose to supplement these roles with additional positions to spread responsibilities
across multiple people and take advantage of specific skill sets.
Role No Start
## Resource Skills Duration
Date
1 EPMO Director Oversight of the project, Issue Program 1 In place Part-time
resolution escalation management
2 Project Manager Day to day management of the Project and 1 In place Full-time
project program
Conformance of solution to management
requirements Licensing
Scope management experience
Project Communications Team leadership
3 Deputy Project Manages different teams/ work Project and 1 In place Full-time
Manager streams as needed, supports program
process development and other management
project Team
communication/coordination Leadership
needs.
4 Information Ensures project is adequately State enterprise 1 In place Full-time
Services Resource resourced from a technical technology
Manager view point, manages technical experience

Role No Start
Date
issues and risks associated with Project
the project, works with the management
Information Services Division experience
Leadership team to address Solution
project issues/risks. leadership
5 Technical Responsible for assisting with State enterprise .5 In place Part-time
Solutionist technical issues and risks technology
associated with the project experience
Project
management
experience
Solution
leadership
6 Product Owner Primary leadership and Strong 1-3 In place Full-time
management of the understanding of
requirements and design of the WA DOL
solution business and
Owns the vision for the future requirements
of operations and the system to Understanding
support it of the vision for
future
operations
7 Subject Matter Work with Deloitte Functional Deep 4-8 In place Full-time
Experts – team to interpret requirements understanding of and Part-
Licensing – and provide configuration data the business and time
Release 2 and information to allow system
development of user stories for requirements for January
their primary area of expertise their area of 2019 – June
First level review of user responsibility 2019
stories and other configuration
and design information
8 Subject Matter Work with Deloitte Functional Deep 6 In
Experts (SMEs) – team to interpret requirements understanding of
Regulatory – and provide configuration data the business and Part-time
Release 2 and information to allow system
development of user stories for requirements for
their primary area of expertise their area of
First level review of user responsibility
stories and other configuration
and design information
8 User Experience Provides DOL standards and Enterprise 1 In place Part-time
practices regarding UX to the system user
implementation team experience
Participates in demonstrations
and playbacks and provides UX
input to the implementation
team
Lease with Deloitte User
Experience staff
9 Financial Lead SME resource for financial Strong 1 In place Full-time
functionality across license understanding of
types. DOL financials

Role No Start
Date
Primary resource to work with Understanding
Deloitte team to capture of future vision
required functionality and for POLARIS
configuration for operations
implementation of financial
and accounting functionality
10 Business Analysts Work with business analysts to Business 8 In place Full-time

interpret requirements, capture requirements
configuration for analysis
implementation
Manage requirements
traceability
11 Integration Lead Works with Deloitte State systems 1 In place Full-time
Integration lead to refine integration
requirements and design Understanding
interfaces of DOL
Primary responsibility for Integration
working with integration environment
partners to have them
undertake required integration
work
Lead integration development
work on internal DOL systems
12 Integration Develop, the internal DOL Interface 1 In place Full-time
Developers integration routines required to development
support interfaces experience
13 Data Conversion Work with Deloitte Conversion Understanding 1 In place Full-time
Lead Lead to map data between of DOL legacy
staging and target data
Oversee the migration of data environment
from source systems to staging
Manage the staging databases
Direct and oversee
transformation activities
undertaken in staging
environment
14 Data Conversion Develop and execute data Data 1 In place Full-time
Analyst migration routines to move data development
from legacy to staging.
Undertake transformation of
legacy data to move to target
format prior to load
15 Testing Lead Works with Deloitte Testing System testing 1 In place Full-time
Lead to develop overall test experience
plan
Develops UAT plans and
manages the execution of UAT
16 Data Tester Validation and testing of Testing 1 In place Full-time
converted data experience
Work with conversion team to
triage data issues and

Role No Start
Date
recommend mapping and
transformation updates
17 Interface Tester Work with the integration team Web user 1 In place Full-time
to develop understanding of the interface design
interface design Salesforce
Develop test scenarios for experience
interfaces
Work with integration partner
to execute test scenarios
Report test results
18 System Config/ Write test scenarios based on Testing 5 In place Full-time
Functional Testers user stories experience
Undertake functional testing of Knowledge of
the application DOL processes
Contribute to the reporting of desirable
test results
19 User Acceptance Run through User Acceptance Knowledge of 10- May 1 – Full-time
Testing – Release Test scripts and report results business 20 May 31,
2 processes, 2020
detailed
oriented,
adaptable to
technology
20 Organizational Plans and manages the OCM Project 1 In place Full time
Readiness activities associated with Management,
manager POLARIS familiar with
OCM activities
21 OCM Analysts Undertake OCM and Experts in OCM 2 In place Full-time
communications activities tools and
associated with POLARIS processes
22 Training Work with Deloitte Training Experienced 1 In place Full-time
Coordinator Lead to develop training plan technical trainer
Plan and manage the execution Understanding
of end user training of DOL
Participate in training materials processes is
development desirable
Training
leadership
experience
23 Trainers – Release Participate in training materials Technical 5 February 1, Full-time
2 development training 2020 –
Deliver end user training experience September
30, 2020
24 Command Center Create command center Command 1 April 1 – Full-time
Lead logistics and make sure center September
processes are set up, ensure experience 30, 2020
command center staffed during
stabilization, and report out on
command center results

Role No Start
Date
25 External QA Provide oversight to project to Expert Quality 1 In place Full-time
ensure proper project Assurance
management processes are in services
place and followed.
26 Administrative Assist with office Administrative 1 In place Full-time
Assistant administrative duties for experience and
project team. skills
Contractor Presence On-Site

Deloitte understands that key to successful delivery of project is for Deloitte and DOL to work together in
collaboration to deliver the system. To that end, Deloitte will have a core team working primarily on site
and integrated with DOL staff throughout the project, especially at periods of key activity, or when
requested by DOL.
Typically, the core project team will be on site Monday through Thursday and work remotely on Fridays.
Deloitte team members may occasionally deviate from this schedule based on circumstances such as
sickness, training, family emergencies. Significant (more than 2-3 days) deviations from the typical
schedule will be coordinated in a manner similar to vacations and holidays described in a separate
section below.
In addition to the core team, Deloitte will have a team of professionals working remotely. Deloitte's core
on-site team will have the primary responsibility to coordinate the work of the remote team members.
Remote team members may occasionally come on site for specific activities as needed.
Contractor Staffing Approach

Except in the event of disability, illness, grave personal circumstances, or separation from service
(“Extenuating Circumstances”), Contractor shall not remove any key staff member from the performance
of the Services prior to the completion of Implementation of Release 2 without DOL’s consent.
Where a key staff member is to be removed from the project due to Extenuating Circumstances, the
Contractor will notify DOL. Contractor will identify a replacement resource for the role within 10 business
days of notification to DOL or 20 business days prior to the scheduled departure of the key staff member,
whichever is later.
Key staff replacements will have qualifications and experience similar to the original key staff member
and will have the skills and experience necessary to complete the key staff assignment. DOL shall have
the right to review the resume of all proposed replacement resource for key staff members and to conduct
an interview of the resource on site in Olympia Washington or via video conference, and check
references. DOL shall have the right to accept or reject the proposed replacement resource.
Contractor Staff On-boarding

Contractor will add additional staff to the project from time to time and will follow a standard on-boarding
process for doing that and obtaining access to the DOL Systems including Salesforce and where
appropriate obtaining a DOL Workstation.
There are three types of access required for Contractor Staff depending on their role. These roles and
their high-level access requirements are provided below.

DOL Workstation Salesforce and DOL Email, DOL Staging

TFS Access SharePoint Database
Access Access
Functional Analyst X X X
Developer X X X X
Remote Staff X
The staff onboarding process will evolve over time. It is documented in the DOL POLARIS SharePoint
repository and can be accessed at:
https://projects.sp.dol.wa.gov/PWA/POLARIS/_layouts/15/start.aspx#/Shared%20Documents/Form
s/AllItems.aspx?RootFolder=%2FPWA%2FPOLARIS%2FShared%20Documents%2FResource%20
Management&FolderCTID=0x01200000F423678A77A541AC56382671F813CB&View=%7BC78B7C0
4%2D1DBF%2D41D9%2D91AA%2D4ABA463C2D31%7D
At a high level, Deloitte will notify DOL of the need for access and or a workstation 2 weeks in advance of
the need.
The majority of Deloitte’s staff will be in either the Business Analysts or Remote Staff category. A very
small number of staff will have the Developer role (generally those associated with data conversion).
Approach to Coordinate Vacation and Holiday Schedules

The project shall follow the State of Washington holiday schedule and non-working days shall be
populated in the project schedule. Deloitte resources will often work outside of standard business hours
and through weekends and holidays in some cases.
Some project activities, most notably the cutover and go-live activities will be scheduled to occur over a
weekend. Those periods will be planned well in advance in order to give Deloitte and DOL staff time to
plan for those periods.
It is understood that DOL and Deloitte staff will continue to take normal vacations and time off through the
course of the project. It is expected that staff on both teams will plan their time off to not unduly impact
the overall project. While staff are away, the respective organization will be prepared to backfill or
otherwise mitigate the impact of the absence.
Monitoring Staffing Levels versus Project Requirements

As the project is being executed by Deloitte on a fixed price basis, Deloitte may, from time to time add or
remove resources from the team to either expedite activities, address schedule or specific content issues
or to reduce staff count where an individual’s services are not required. Staff designated as key will be
maintained throughout the project and their availability managed according the processes laid out in the
Contract and Statement of Work.
Both Deloitte and DOL are expected to adjust staffing levels to allow for accomplishment of their
responsibilities in a way to conform to the approved project schedule. Adjustments may be required to:
 Add additional resource hours to accelerate a task that is falling behind schedule
 Increase testing resources to allow for completion of test execution once the number of test
scenarios is known
 Add trainers or number of training sessions to allow for completion of training activities within
allotted schedule

Reporting on Resources
Ensuring the project is adequately resourced is a key project performance metric and is reported as part
of the monthly status report. If resources are not available as planned in the resource management plan
and the delay creates new risks of preventing project from delivering on-time, the status report will reflect
“yellow.” If resources are not available as planned in the resource management plan and the delay is
causing delays in project delivery, status report will reflect “red” for resources.

5 Schedule Management
Consistent, high-quality schedule management processes allow PMs to understand the current situation,
forecast the future, accurately assess the impact of changes, prioritize team efforts, and effectively
communicate both internally and externally. Project team coordination requires a structured process to
confirm that the team develops, baselines, maintains, and reports status against the project Work Plan. A
key to building and maintaining a good Work Plan that will accurately model the project is to keep the
Work Plan as simple, yet realistic, as possible.
Key Schedule Management Concepts

 Dynamic scheduling. The schedule will be built as a dynamic, integrated Work Plan with a clearly
identified critical path. In conjunction with the Team Leads, the PM will link the tasks using
predecessors and successors as opposed to using date constraints. Whenever a task date
changes, this approach will allow the scheduling tool to automatically update the entire Work
Plan, thereby displaying the impact of performance variances upon the critical path.
 Rolling wave planning. The project team will use the concept of a Rolling Wave planning
approach to Work Plan development. The fundamental concept underlying Rolling Wave planning
is to develop a high-level Work Plan for the entire project lifecycle at the outset of the project and
then refine and add more detail at the beginning of each project phase.
The Rolling Wave planning approach defers the time and effort to build detailed plans before
those detailed plans are useful. However, it is important to note that Rolling Wave planning is
plan refinement, not re-planning. Should a team member seek significant changes to the Work
Plan during schedule refinement that would add or delete scope, or adversely impact time or cost
goals, they must prepare and submit a Change Request.
In the case of POLARIS, it is intended to create a schedule that is largely complete. The PM
team will have the option of adding additional detail or modifying approaches as the schedule
advances through the various major scope elements.
 Milestones. Each project Work Plan will include milestones to show completion of major activities,
contractual deliverable events, and phase ends. It will also include milestones to reflect key
external dependencies. An external dependency exists when a group or team outside the
boundaries of the project produces a deliverable or completes a task required to complete the
project. An external dependency represents a schedule risk to the project and must have an
appropriate risk included in the risk register.
 Deliverables. The Work Plan should include every deliverable included in the scope of Work. In
addition, for each deliverable, the quality review cycle should be included in the project Work
Plan.
 Schedule Update Look Ahead Document. The project team will use these to solicit Work Plan
updates from the project team.
Approach to Schedule Management

Schedule management includes the processes to establish the initial schedule as well as baseline the
schedule
5.2.1 Develop and Baseline

To develop the Work Plan in preparation of the baseline, the project team should:

 Conduct Preliminary Planning and Logistics

 Define Scope based on the SOW, break it down into manageable WBS elements and estimate
durations and assign owners
 Establish Network Dependencies
 Baseline and Publish Work Plan
5.2.2 Track Progress and Maintain
To effectively monitor actual versus planned, the project Work Plans will be regularly updated and
maintained throughout the life of the project. The PM, supported by the PMO Analyst, will update the
project Work Plan weekly following baselining of the schedule. The update process includes the following
steps:
 Create and distribute Schedule Update Look Ahead Document
 Document progress
 Review progress updates
 Update the Work Plan and create reports
 Analyze the results and determine corrective actions
 Document corrective actions
 Update project schedule, if applicable
Task owners will provide updated status on the Look Ahead Document that is circulated weekly.
 Tasks that have not started will be reported as not started.
 Tasks that have started and are less than 5 days in duration will be reported as 50% complete.
 Tasks that are more than 5 days in duration will be reported as 20% complete once they are
started until they are complete.
 Tasks can be marked 100% complete when they are fully complete
Task status will be collected weekly from Task owners and be updated in the project schedule. The
PMO staff will then calculate a schedule variance based on the percent complete against expected
percent complete at that point in the project.

5.2.3 Refine and Revise
Should it be determined that more detail or refinement is required in the schedule as the project moves
forward, a Rolling Wave style planning process will be scheduled to make those changes. During the
Rolling Wave planning activities, the PM and Team Leads will refine and revise the schedule. The PM will
initiate the process with a phase planning meeting, including the PM leads of the various work-streams,
and the PMO scheduler (if possible). During this meeting, the PM will describe the scope of the plan
refinement activity and the process for refining the schedule. The group will discuss the major activities for
the team to refine and determine the approach. The various leads of the work-streams will create a
concise written summary of the major activities in the next phase for which their team is responsible. The
summaries will include the following for each major activity:
 The overall approach

 Quality Control activities

 Roles and responsibilities at a summary level
 Key needs from other teams
 Major risks
A list of the internal challenges for the activity (i.e., those elements, components, or aspects that they
know will be challenging to complete)
Rolling Wave planning is plan refinement, not re-planning. Should changes to the Work Plan be identified
during Work Plan refinement, a Change Request is prepared and submitted to request the change. The
PMO will only re-baseline with changes or refinements made to the Work Plan once the request is
approved per the Change Control Process.
5.2.4 Rebaseline (as approved)
Where significant changes are required to the schedule (due to a scope change or unforeseen
circumstances then it may be necessary to re-baseline the schedule to make ongoing management of it
more realistic. The PM and the PMO will collectively control changes to the baselined Work Plan per the
Change Control process.
Frequency of Updates
The project schedule shall be updated weekly after the first baseline is created. Results of the update
will be communicated as part of status reporting. More substantive updates may occur to the project as
part of Rolling Wave updates as often as once every two to three months depending on the needs.
Small changes to the schedule (addition of small numbers of tasks or adjustment of dependencies) may
occur as often as weekly as required to address schedule adjustments and in reaction to task schedule
slippages or other issues.
Level of Granularity of Tasks

As a general rule, tasks will be decomposed to be no more than 20 working days in duration. Where
practical, tasks should be decomposed to 5 or fewer days in duration. Where tasks are longer than 5
days, they should be targeted for decomposition into smaller tasks as part of the weekly update process.
Distribution, Storage, and Access to the Plan

The project plan shall be stored in the POLARIS SharePoint site for general access as a PDF file. This
file will be updated weekly and stored for historical tracking purposes in SharePoint. Access will be
provided to a Microsoft Project version of the schedule to users who request such access. The master
version of the schedule shall be stored in a private folder in SharePoint with restricted access. This
version shall be managed and updated by the Deloitte PMO Analyst as part of the Project Scheduling
activities.
Roles and Responsibilities for Schedule Updates
## Task Responsible Date

1 Develop Initial Project Schedule Deloitte PM January 2020
2 Baseline Project Schedule DOL PM January 2020
Deloitte PM
3 Publish Task Assignments (2 weeks Deloitte PMO Analyst Monday
out) (Schedule Look Ahead Document)
4 Update Status in Look Ahead All Task Owners Tuesday
Document and return to PMO

## Task Responsible Date

5 Collect status from Look Ahead Deloitte PMO Analyst Wednesday
Document and compile
6 Update project schedule with status Deloitte PMO Analyst Thursday
updates
7 Assess impact Deloitte PMO Analyst Friday
Assess progress to plan
8 Develop Mitigation approaches Deloitte PM Monday
9 Compile schedule impact information Deloitte PMO Analyst Monday
for Status Report
10 Lead discussion of Schedule impact in Deloitte PMO Analyst Tuesday
Status Meeting
11 Approve mitigation recommendations / DOL PM Tuesday
actions Deloitte PM
12 Update Schedule with mitigations Deloitte PMO Analyst Thursday
13 Publish revised Schedule Deloitte PMO Analyst Friday
14 Identify need for Re-planning DOL PM Periodically
Deloitte PM
15 Request Baseline Update DOL PM As Required
16 Approve Baseline Update Business or Executive Sponsor As Required
17 Conduct Baseline Update Deloitte PM As Required
DOL PM
Approach to Tracking Progress versus Plan

The schedule status shall be set to “yellow” if the project schedule variance is 5% to 9 % behind schedule
and set to red if the schedule variance is 10% or more behind schedule.

6 Communication Management Plan
Communication Approach
This Communication Management Plan documents the protocol for the Project team to communicate
internally and with the POLARIS stakeholders with the objective to structure communication in an
effective way and to define high level responsibilities for communications. The Communication
Management Plan documents the information needs, activities and methods needed to facilitate timely
and appropriate generation, dissemination, and disposition of project information.
This plan is intended as a starting point to establish the minimum expectations for communications.
Additional methods and opportunities will be sought and employed as appropriate.
Status Report
The project management team will generate two status reports. The first, a weekly report will be
generated by the Deloitte Project Management team but will incorporate status from both the Deloitte and
DOL staff working on the various threads of work. It is relatively detailed and reports on the individual
threads of work. It is intended for the core project leadership team to communicate status of the project
execution and keep the on the ground project leadership appraised of status on the ground.
The second, a monthly status report will be generated by the DOL Project Manager with support from
Deloitte and will report on the high-level status of the project meant for an executive audience (primarily
the Steering Committee).
6.2.1 Weekly Status Report
The weekly status report is structured as a power point deck with a slide for each thread of activity
currently underway (i.e. functional, conversion, integration, OCM), a dashboard and a link to the
Deliverable tracker. The report dashboard that reports overall status of the project as well as the
performance metrics from the development sprints.
Select risk and issues that need to be discussed on a weekly basis are also brought forward in the weekly
status report.
6.2.2 Monthly Status Report
The monthly status report is structured as a narrative document. It reports the project status at a higher
level intended for the steering committee and other executive audiences. The monthly status report
includes:
 Dashboard showing key performance indicators
 High level description of the status by major thread of activity
 Performance against milestones
 Extract of key risks and issues from the respective trackers
Stakeholders and Communication Needs

The following table describes Deloitte’s approach to communicating project impacts throughout the life of
the project. Deloitte recognizes that Project communications are the primary tool for promoting
cooperation, participation, coordination, and an understanding of acceptance between all project
stakeholders. The POLARIS Project has the following primary stakeholder groups, with specific
communications roles and needs delivery vehicles and responsibilities for each as indicated in the table
below:

Primary Delivery Primary

Audience Roles Information Needs
Vehicles Responsibility
Deloitte and  Address  Project progress  Weekly DOL and
DOL POLARIS escalated  Key issues and risks meeting Deloitte PM
Leadership issues quickly  Meeting notes
 Change Requests
Steering  Provides  Schedule and IT project  Monthly DOL Project
Committee project status written status Manager
oversight to  Financial requests and report
enable the IT budget status  Monthly
project to Steering
 Identification of risks
meet the Committee
and risk mitigation
business Meeting
strategies
needs
identified by  Formal status reports at
the Board on key stages
time and  Notice of significant
within budget deviations from
schedule or budget
Working  Provides input  High level insight into  Weekly DOL Product
Committees to the project progress meetings with Owner
requirements  Information on how Product
process requirements are being Owner
 Reviews addressed
status and  Expected changes to
provides input operational processes
to specific moving forward
questions
from project
leadership
 Business
decisions
Boards and  Govern  High level insight into  Periodic DOL Readiness
Commissions licensed project process meetings with Manager
professions  How project functionality DOL
 Represent is being addressed
consumers of  Changes to be expected
DOL Services from system in licensing
process
Project  Manage day  Detailed status of the  Weekly status DOL and
Management to day project report Deloitte PMs
execution of  Information regarding  Weekly status
the project outstanding decisions, meeting
 Lead threads risks, issues and action  Monthly Risk
of activities items and Issues
meetings

Primary Delivery Primary

Audience Roles Information Needs
Vehicles Responsibility
Project Team  Execute day  Expectations on work  Daily Standup Team Leads
to day delivery required Meetings
of project  Information regarding  Access to
work reference Weekly Status
documentation available Report
 Information regarding  Periodic all
external influences on hands
the project meetings

7 Quality Management Plan

The purpose of the Quality Management Plan is to define the objectives, processes, tools, and roles and
responsibilities required to implement an effective quality management program.
Deliverable Review Process

7.1.1 Overview
A “Deliverable” is a work product that is explicitly defined in the Statement of Work (SOW). A project work
product that does not require sign-off may still be reviewed with DOL to confirm alignment. In certain
cases, one contractual deliverable might contain multiple individual. This section describes the
processes, assets, and protocols to develop and manage project deliverables through client acceptance.
Deliverable Management is outlined as follows:
7.1.2 Define Deliverable Expectations
The project team collaborates to update the Deliverables Log in the Project Management Plan at the
beginning of each release. The Deliverables Log will include the project deliverables that require sign-off.
The Deliverables Log documents deliverable expectations, including:
 The Deliverable Expectations Document (DED) for a deliverable which documents acceptance criteria
for the deliverable. A deliverable expectation document can be created by tailoring the standard
Deloitte method template for the deliverable to meet project-specific needs; and then working with the
DOL team members responsible for review and sign-off to define and document the deliverable
acceptance criteria (i.e., “DACs”) in the document. The DEDs should also contain:
 DOL staff position responsible for participating in deliverable reviews and review timelines. Every
deliverable requires at least one deliverable review.
 DOL resources accountable for deliverable sign-off.
7.1.3 Draft Deliverable
The project team member(s) assigned to the deliverable create(s) the draft deliverable using the
appropriate template. Ideally, this deliverable development step will not start until the Deliverable
Expectation Document for the deliverable has been signed-off, and the reviewers for the deliverable
review(s) have been defined. In some cases, the deliverable development work may begin before the
sign-off of the DED if this is required to meet the deliverable deadline. In such cases the draft Deliverable
will need to be updated to match the final sign-off DED.
DOL team participation in the “Draft Deliverable” step is important. The DOL team members will
participate actively in the development of deliverables and/or provide inputs.
7.1.4 Review Deliverable
Once drafted, the deliverable review(s) planned for the deliverable will be performed. In cases where
different client reviewers have contradictory or mutually exclusive feedback, the DOL Project Manager will
work with them to reconcile their feedback. If disagreements remain, an issue will be documented and
escalated. Deliverable reviews will be completed in a timely manner, consistent with the durations
documented in the Deliverable Log and updated in the approved DED.
Once the planned deliverable reviews are complete and the documented feedback has been adequately
addressed, the deliverable is ready to be shared with the appropriate DOL stakeholder(s) for sign-off.
7.1.5 Sign-off Deliverable
The DOL resource(s) identified in the Deliverables Log will review the completed deliverable and the
documentation supporting the review activities. During the sign-off process, the reviewer may provide
additional feedback which will be documented and addressed. The reviewer will sign-off or provide

feedback on the deliverable within the time period documented in the Deliverable Log. For standard
deliverables (non-payment milestones), upon completion, the reviewer will document deliverable sign-off
by noting approval in the file and sending an email to the Deloitte Deputy PM and Deloitte PMO Analyst.
For deliverables that are tied to a milestone payment, approval is provided by hand-written signature in a
deliverable approval form.
Once a deliverable is signed off, the DOL and Deloitte project manager(s) will archive the approved
deliverable (along with the completed Deliverable Sign-off Form) in POLARIS SharePoint site, and any
additional changes to the deliverable will need an approved change request.
Due to the iterative nature of the development on the POLARIS project, the following Deliverables will not
require a change request if changes are introduced during the development phase (before the start of
SIT):
 Deployment Plan **
 High Level Application Design *
 Solution Architecture *
 Interface Agreement, Specification, and Mapping Document *
 Integration Design Document *
 Data Dictionary *
 Data Conversion Plan
 Data Conversion Mapping Source to Staging
 Data Conversion Mapping Staging to Salesforce
 Test Plan
Initial signed-off versions of the above Deliverables will serve as a baseline version. Changes to these
Deliverables can happen throughout the development phase to reflect design decisions. Documents
marked with a single asterisk * will be updated throughout the project to reflect design changes. No
formal resubmission will be conducted. The Deployment Plan, marked with two asterisks ** will be
submitted for a second review during User Acceptance Test. This updated version will reflect the
updated deployment activities that would be required to deploy a new environment during production
operations. The balance of the deliverables are working documents are will only be updated should a
significant deviation be required in the process during the period of applicability of the deliverable.
7.1.6 Deliverable Reviews

Deliverable reviews aim to detect defects. Before a deliverable goes through the deliverable sign-off
process, deliverable reviews are performed by the Deloitte project team to:
 Verify the completeness of a deliverable
 Verify the accuracy of a deliverable
 Verify that a deliverable meets the corresponding Deliverable Expectation Document
 Verify that the content of a deliverable meets its objectives and is consistent with prior approved
deliverables
The project will plan the type of review for each deliverable in the project’s Deliverables Log. Each
deliverable review cycle will follow one of the following approaches:

Formal Review: Formal reviews represent the most structured review type and are used as development
step for critical designs or deliverables with cross-team impact. They often follow a walkthrough or offline
review for the same deliverable.
The formal review takes place as a scheduled, facilitated meeting between two or more reviewers, after
previously providing the deliverable and review criteria in advance of the meeting to all review
participants. Formal reviews are not meant to be conducted as walkthroughs. Reviewers must come
prepared to share their findings from their individual preparation review with the other reviewers. There
may even be a kickoff or preparation meeting with the reviewers before the formal review session. The
consensus review defects are documented in one feedback document and/or marked up copy of the
deliverable and agreed-upon changes must be implemented and verified before the formal review is
considered complete.
Walkthrough Review: Walkthrough reviews are an effective deliverable review type for medium-risk
deliverables or deliverables that may be hard to understand (for example, complex technical design
documentation).
The format of this walkthrough review is a face-to-face meeting where the authors of the deliverable walk
a reviewer group through the deliverable. The reviewer group should include at least two individuals, with
at least one subject matter expert. The review defects are documented in one deliverable feedback
record and agreed-upon changes are resolved and verified in the deliverable before the walkthrough is
considered complete.
Offline Review: Offline reviews are performed by someone other than the deliverable author in a
distributed or asynchronous manner (that is, not a face-to-face meeting or live teleconference).
Each offline reviewer uses the Deliverable Feedback Form (DFF) and the corresponding Deliverable
Expectation Document to evaluate the deliverable, identify defects, and document feedback. The DFF is
provided to the deliverable author for resolution. The owner of the deliverable review assignment will
verify that all defects are resolved before the deliverable review can be considered complete.
Work Product Review Process

Work Products are documents and other artifacts that are produced as part of the design and build
process to address specific needs of the project and that do not require formal sign-off.
Depending on the nature of the Work Product it may go through a review process similar to the review
process for Deliverables, but the review process will typically be less formal than deliverables.
Roles and Responsibilities

The following table illustrates Roles and Responsibilities for preparation, review, and approval of
deliverables:
Deliverable/Activity Deloitte Responsibility DOL Responsibility

Deliverable Expectation Document
Create and submit a Deliverable Expectation Document Primary Support
Review and Approve a Deliverable Expectation Primary
Document
Draft Deliverable
Create and Present Deliverable Primary Support
Update and Complete Deliverable Primary
Final Deliverable

Deliverable/Activity Deloitte Responsibility DOL Responsibility

Submit Final Deliverable Primary
Deliverable Review Support Primary
Incorporate Feedback Received on Deliverable Primary
Submit Final Deliverable Version Primary
Deliverable Approved Primary

8 Risk and Issue Management Plan

This section documents the process, templates, and tools that the project will use to identify, evaluate,
and manage risks throughout the life of the project. A risk is an event that has not occurred that will, if it
does occur, impact the project schedule, scope, budget, or quality.
Risk Management Process

Risks are situations that are identified that may adversely impact the project scope, schedule or cost
should they come to pass. Risks must be proactively tracked and managed in order to avoid adverse
impacts on the project.
8.1.1 Risk Management Process

The flow-chart below summarizes the project’s risk management process:
Project
Management
Plan
1. Identify and 2. Is Risk 3. Develop Risk

Yes
Analyze Risk Severity High? Response
No
5. Is the Risk 6. Manage

4. Monitor Risk Yes
Realized? Issues
No
Yes 7. Is the Risk

No 8. Close Risk
Active?
Risks Log
Legend
Inputs / Supporting
Task Outputs Step Output Procedure Decision
Step 1 - Identify and Analyze Risk

At the beginning of the project and then twice-monthly during the risk review meeting (see Risk Meetings
section), project managers and team leads will identify risks that can negatively impact project outcomes.
The Risks Log for this project will be stored in POLARIS SharePoint.
 Risks are identified during risk meetings organized by the project manager (see Risk Meetings
section below)
 Initial project risks that were identified as part of upfront project planning and documented in the
Project Charter are reviewed during the initial risk review meeting
 As risks are identified, the following information will be captured:

Field Description
Title Brief, high-level description of the risk
Owner Project team member responsible for ensuring that the risk is properly
analyzed and addressed
Assigned To Project team member responsible to develop and implement the risk
response plan
Status Status of the risk as it flows through the process
Category Identifies the type of risk. Options (definitions are provided in section 8.3
Risk/Issue Types):
 Contract
 External
 Financial
 Functional
 Quality
 Organization
 Performance
 Project Management
 Resource
 Schedule
 Scope
 Technical
 General
Due Date Date when the mitigation plan is due
Probability Likelihood of the risk occurring Options:
1 – Low
3 – Medium
5 – High
Impact Magnitude of impact should the risk actually happen. Options:

1 – Low
3 – Medium
5 – High
Severity  Magnitude of the risk:
 Probability * Severity
 Low = 1-3
 Medium = 5 – 9
 High = 15 - 25

Cost Cost impact in dollars ($) should the risk actually occur
Description Likely causes and consequences of the risk
Mitigation Plan Approach to reduce or eliminate the likelihood of the risk occurring
Contingency Plan Fallback plans should the risk occur

Trigger Description Description of outcomes or results that indicate the risk has occurred
Trigger Condition that triggers the contingency plan
Options:
 Date – date of occurrence
 Exposure over threshold – risk probability exceeds acceptable level
 Tasks not completed – assigned work was not done
 Other
Step 2 - Develop Risk Response

For severity risks that require a response plan, the assigned team member(s) (i.e., risk owner(s)) will
analyze the risk in more detail, determine the appropriate risk response strategy and develop the risk
response plan:
 Risk response – Proposed risk response strategy
 Accept – accept the risk, but monitor it
 Mitigate – determine actions to eliminate or reduce the risk
 Transfer – transfer the risk responsibility to another group
 Mitigation plan – plan to mitigate the risk with the appropriate details for the risk response
strategy selected
 Contingency Plan – Identify actions to take as a backup plan if the initial risk response plan does
not work
Once the risk owner completes his/her risk assessment and proposed risk response strategy and
response plan, the risk meeting team needs to review and approve the plan, which may not occur until
the next risk review meeting, unless the risk’s priority is “Critical” or “High,” in which case a special risk
meeting may be organized to review and finalize the risk strategy, response plan, and contingency (i.e.,
“backup”) plan for the risk.
Step 3 - Monitor Risk

The project managers monitor the risk throughout the life of the project, for as long as the risk remains in
active status.
 Determine the appropriate new risk owner(s) if the risk assignment needs to change.
 Where necessary, update the risk assessment, response, or other details.
 Determine if or when a risk needs to be escalated to the next project level.
Step 4 - Determine if Risk is Realized

As part of risk monitoring, the project managers determine whether the risk has been realized on the
project by the risk trigger.
 For realized risks, follow the risk realization steps included in the approved risk response plan
(where applicable), and log a new issue in the project’s Issues Log for the realized risk.

 Once the issue record is created, cross-reference the new issue ID in the old risk record before
closing the risk record.
 If the risk has not been realized, continue monitoring it throughout the project, for as long as the
risk is active.
Step 5 - Manage Issues

For a realized risk that converts to a project issue, address it using the project’s standard issue
management process.
Step 6 - Determine if Risk is still Active

Determine the status of the risk:
 If the risk is no longer active, proceed to closing the risk.
 If the risk is still active, continue monitoring the risk, escalating when necessary.
Step 7 - Close Risk

Update the Risk Log in POLARIS SharePoint by setting the risk status to Closed.
8.1.2 Risk Severity Scoring Matrix

When risks are identified, they will be qualitatively analyzed in terms of impact and probability. Impact and
probability will both be assessed on a range of 1 – 5, with 1 being Low and 5 being High. The two values
will then be multiplied to compute an overall risk severity. The table below outlines the complete set of
values and the severity level for each combination.
The determination of severity will be done collaboratively during the risk review meetings (see
subsequent section for risk meeting planning). The project team will create a formal risk response plan for
risks that are determined to be High severity. Other risks will be monitored and reviewed but will not have
formal risk response plans. Risk response planning will be a joint responsibility between DOL and Deloitte
resources.
8.1.3 Risk Monitoring

Active risks will be tracked and published in the SharePoint Risk and Issues log. Weekly Project Status
Report may not include all tracked risks, only those with higher priority at the discretion of the project
managers, as well as newly identified risk since the last status report.
A risk that is realized will either: (1) Initiate the approved response plan defined for the risk; or (2) Be
logged as a new issue to be addressed by the project’s defined impediment management process.

8.1.4 Risk Meetings

Project leadership (i.e., project managers and team lead) will meet monthly to review and add/update
risks. This meeting will be scheduled by the Deloitte project manager. The table below describes
additional details regarding the monthly risk review meeting.
Meeting Logistics Project Plan

Meeting Frequency Monthly (combined with Issue meeting)
Participants Project Managers, Team Leads, Product Owner, PMO Staff, DOL QA
Attendees needed for a Quorum Three people, including at least the DOL and Deloitte Project Managers
Meeting Agenda  Review active risks to determine if probability or impact has changed, or whether
any risks can be closed
 Identify new risks (and determine probability and impact)
 Assign responsibility for creating formal risk response plans for any “High”
severity risks that don’t currently have plans (could be an existing risk with a
changed assessment and severity score or a new risk)
 Review drafts of new risk response plans
 Determine if any risks need to be escalated
After each risk review meeting, the DOL project manager has the following responsibilities:
• Validate Risk Log is updated with changes and additions
• Archive any approved risk response plans
• Communicate the updated risk records
Issue Management Process

This section documents the process, and tools that the project will use to identify, evaluate, and manage
issues throughout the life of the project. An issue is an event that has occurred that will impact the project
schedule, scope, budget, or quality.
The flow-chart below summarizes the project’s issue management process:

Project
Management
Plan
4. Manage
3. Change
1. Create Issue 2. Resolve Issue Yes Change
Request?
Requests
No
5. Close Issue
Issues Log
Legend
Inputs / Supporting
Task Outputs Step Output Procedure Decision
Step 1 - Create Issue

Project team members identify issues impacting the project and document them in the project’s issue
logging tool, which will be the Issue Log on POLARIS SharePoint site.
 Any project team member can identify a project issue at any point in the project lifecycle.
 The person identifying and logging the issue needs to provide as much information as possible on
the new impediment.
Field Description
Action/Issue Designate whether the item is an Action or an Issue
Action/Issue Status Status of the issue as it flows through the process. Options:
 New – recently created
 In-progress – currently working on the item
 Blocked – unable to proceed
 On-hold – delay action on the item
 Closed – complete
Title Brief, high-level description of the issue
Release Impacting? Release that is affected by the issue. Options:
 Release 1
 Release 2
 Both
Category Identifies the type of issue. Options (definitions are provided in section 8.3
Risk/Issue Types):
 Contract
 External

 Financial
 Functional
 Quality
 Organization
 Performance
 Project Management
 Resource
 Schedule
 Scope
 Technical
 General
Description Details on what the issue is, what’s causing the issue, the impacts, and the
resolution actions. The resolution actions include:
 Resolution approach
 Whether a change request (CR) needs to be created to close the issue
 Other closure criteria
Priority A subjective assignment of the significance of the issue used by the project
manager for prioritization and status reporting. The priority issue ratings for the
project are as follows:
 Critical - the issue resolution actions must be defined and executed
immediately (Severity Level 1)
 High - the issue resolution actions must be defined and executed as
soon as possible (Severity Level 2)
 Medium - the issue resolution actions can be developed any time
before the next risk and issue review meeting (Severity Level 3)
 Low – the appropriate issue resolution actions will be determined at
the next risk and issue review meeting (Severity Level 4)
Assigned To Project team member responsible for addressing the issue and developing a
resolution plan
Due Date Date when resolution is required to be complete
Related Identify any other related issues or actions
Issues/Actions
Related Risk ID ID for risk associated with issue
Comments Free text field to provide additional information
The DOL and Deloitte project managers review and validate “New” issue records from the project team,
canceling issues entries that are not valid. The project managers will then confirm or re-assign valid
issues to the appropriate project team member(s) (issue owners) for detailed analysis and resolution
planning.
The assigned team member(s) will confirm or define the following fields for an issue record after
completing the necessary due diligence and analysis on the issue. Where appropriate (e.g., for “Critical”
or “High” priority issue), the project managers should review and approve the proposed issue resolution.
Step 2 - Resolve Issue

The issue owner works to manage the issue to a successful close.

 Implement the resolution actions to close the issue. Determine whether the resolution actions
require a Change Request (see next step).
 Document the resolution results.
 If the issue cannot be resolved, escalate the issue.
Step 3 - Change Request Required to Resolve the Issue

The issue owner makes an assessment as to whether or not a change request is required to perform the
issue resolution steps.
 If an issue's resolution actions require work outside the defined scope for the project or changes
to signed-off project documents, the issue owner needs to consult with the DOL and Deloitte
project managers to determine whether or not a change request needs to be created
 See section 3.6 Change Control Process, Roles, and Responsibilities for guidance on the change
request process
Step 4 - Manage Change Requests

Perform the Manage Change Requests task to see if the change request to resolve the issue is approved.
 No work on the issue resolution steps can be performed until the associated change request (CR)
for the issue is approved by the project’s Change Control Board (CCB).
 Issue CRs that are not approved will need to be set to “Closed” or “Cancelled” status, as
appropriate.
Step 5 - Close Issue

Confirm that the resolution steps completed resolved the issue successfully.
 The appropriate stakeholder(s) identified for the issue should help confirm the issue resolution.
 For issues where resolution is confirmed, update the status of the issue in the Issue Log to
"Closed"
 Issue where the resolution results were not confirmed will remain in “In Progress” status until they
can be successfully confirmed.
8.2.1 Issue Monitoring

Unresolved Critical issues will be reported in the weekly Project Status Report; unresolved High and
Medium issues greater than 1 week and 2 weeks past due respectively will also be reported. Unresolved
Critical and High priority issues, and Medium issues 4 weeks past due will be reported in the monthly
Executive Steering Committee Report.
8.2.2 Issue Management Meetings
Issue identification and resolution is an ongoing process. Identifying and resolving issues in a timely
manner is a critical success factor for the project, and both DOL and Deloitte staff need to commit to
supporting timely issue resolution.
The issue meeting plan described in the table below will address project issue:

Meeting Logistics Issue Meetings

Meeting Frequency Weekly (
Participants Project Managers, Team Leads, Product Owner, PMO Staff, DOL QA
Attendees needed for a Quorum Three people, including at least the Deloitte and DOL Project Managers
Meeting Agenda  Announcements
 Review “New” impediments
 Review any “In Progress” impediments that need attention
 Determine if any impediments need to be escalated
Risk/Issue Types
The following risk and issue types will be used to categorize identified risks in the Risk Log, and issues in
the Issue Log respectively.
Risk/Issue Type Risk/Issue Type Description

Contract Any risk/issue related to the contracts of the project (such as a signed agreement between
Deloitte and DOL or subcontractors / third parties).
External Any risk/issue related to environmental factors largely outside the control of the project (such as
cultural, legal, or regulatory).
Financial Any risk/issue related to the budget or cost structure of the project (such as increase or decrease
in the project-related budget).
Functional Any risk/issue related to the overall function of the product (such as requirements or design)
being developed by the project.
Quality Any risk/issue related to the quality requirements of the project.
Organization Any risk/issue related to internal, DOL, or third-party organizational or business changes (such
as executive leadership role changes).
Performance Any risk/issue associated with the performance of the application (such as response time, stress
testing, and development environments).
Project Management Any risk/issue related to the management of the project (such as communications, status
reporting, and impediments management).
Resource Any risk/issue related to project resources (such as the addition or removal of resources)
Schedule Any risk/issue related to the Work Plan and related tasks (such as extensions or reductions of the
project timeline).
Scope Any risk/issue related to project scope (such as process, module, and development objects).
Technical Any risk/issue related to software or hardware, including infrastructure related to the project.
General Any risk/issue that cannot be categorized into one of the above categories.

9 Project Organization
The project organization is documented in an integrated organization chart in SharePoint. It can be
accessed at:
https://projects.sp.dol.wa.gov/PWA/POLARIS/_layouts/15/start.aspx#/Shared%20Documents/Form
s/AllItems.aspx?RootFolder=%2FPWA%2FPOLARIS%2FShared%20Documents%2FProject%20Go
vernance&FolderCTID=0x01200000F423678A77A541AC56382671F813CB&View=%7BC78B7C04%2
D1DBF%2D41D9%2D91AA%2D4ABA463C2D31%7D
Titled: Integrated Org Chart

10 Deliverables Log
Project deliverables are outlined in the table below along with the primary review and approval
assignments and the review durations expected.
Deliverables Log

About Deloitte
Deloitte provides audit, tax, consulting, and financial advisory services to public and private
clients spanning multiple industries. With a globally connected network of member firms in
140 countries, Deloitte brings world-class capabilities and deep local expertise to help
clients succeed wherever they operate. Deloitte's 200,000 professionals are committed to
becoming the standard of excellence.
Usage Statement
This publication is for internal distribution and use only among personnel of Deloitte Touche
Tohmatsu Limited, its member firms, and its and their affiliates. Deloitte Touche Tohmatsu
Limited, its member firms, and its and their affiliates shall not be responsible for any loss
whatsoever sustained by any person who relies on this publication.
If you will be using this template to prepare document for delivery external to Deloitte, you
are required to add the appropriate member firm disclaimer statement.
©2015. For further information, contact Deloitte Touche Tohmatsu Limited.


POLARIS Project Management Plan Release 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

POLARIS Project Management Plan Release 2

Uploaded by

Copyright:

Available Formats

POLARIS

Washington Department of Licensing

Project Management Plan Release 2

Document Control Information

Document Name Project Management Plan Release 2

Project Name POLARIS

Client Washington Department of Licensing

Document Edit History

Version Date Additions/Modifications Prepared/Revised by

Document Review/Approval History

2/5/2020 Page 1 of 50 POLARIS

2/5/2020 Page 2 of 50 POLARIS

Level of Granularity of Tasks ........................................................... 30

2/5/2020 Page 3 of 50 POLARIS

2/5/2020 Page 4 of 50 POLARIS

2 Project Goals and Objectives

The Charter goes on to list specific Project Objectives:

2/5/2020 Page 5 of 50 POLARIS

2/5/2020 Page 6 of 50 POLARIS

3 Scope Management Plan

Scope and Schedule

2/5/2020 Page 7 of 50 POLARIS

3.1.4 Reporting on Scope

Design and Implementation Principals

2/5/2020 Page 8 of 50 POLARIS

Governance Structure for System Design Decisions

Information, Processes, and Tools to Manage Requirements

Approach to Tracing Requirements Compliance

2/5/2020 Page 9 of 50 POLARIS

Change Control Process, Roles, and Responsibilities

3.6.1 Formal Change Control Process

Change Request Status Status Definition

2/5/2020 Page 10 of 50 POLARIS

Change Request Status Status Definition

Handling a Change Request

Change Request Criticality Definition

2/5/2020 Page 11 of 50 POLARIS

Roles and Responsibilities

Role Change Management Responsibility

Steering Committee  Approve or deny high-impact Change Requests

2/5/2020 Page 12 of 50 POLARIS

Role Change Management Responsibility

Handling a Change Request that DOL has decided to pursue

Monitoring Progress Against Scope

2/5/2020 Page 13 of 50 POLARIS

2/5/2020 Page 14 of 50 POLARIS

2/5/2020 Page 15 of 50 POLARIS

2/5/2020 Page 16 of 50 POLARIS

4 Resource Management Plan

Project Work Streams Roles and Responsibilities

2/5/2020 Page 17 of 50 POLARIS

Data cleaning focuses on achieving required level of

2/5/2020 Page 18 of 50 POLARIS

## Resource Role Skills No Logistics

2/5/2020 Page 19 of 50 POLARIS

## Resource Role Skills No Logistics

2/5/2020 Page 20 of 50 POLARIS

## Resource Role Skills No Logistics

2/5/2020 Page 21 of 50 POLARIS

2/5/2020 Page 22 of 50 POLARIS

10 Business Analysts Work with business analysts to Business 8 In place Full-time

2/5/2020 Page 23 of 50 POLARIS

2/5/2020 Page 24 of 50 POLARIS

Contractor Presence On-Site