OneWa-003DEL-Project Management Playbook

One Washington (System Integrator K3298 SOW_1A)
Project Management Playbook

___
March 10, 2021
Version 0.9 Page 1 of 169

03/10/2021
Document Control General Information
Type of Information Document Data

Title Project Management Playbook
File name OneWa-003DEL-Project Management Playbook.docx
File Location SharePoint
Original Release Date 02/09/2021
Current Release Date 03/12/2021
Vendor Deloitte
PMP Owner Lizzy Drown
PMP Reviewers Lizzy Drown
Matthew Meacham
Vann Smiley
Julie Thumser-Kerlee
Liz Colón, ISG
John Cook, ISG-PS
Thomas Ortiz, ISG-PS
Allen Mills, bluecrane
Jay Jackson, bluecrane
PMP Approver Matthew Meacham, One Washington Program Director

03/10/2021
Version Control
Version Number Date Additions/Modifications Prepared/Revised By

v0.1 1/27/2021 Initial Draft Mike Baum/David
Boeker
v0.2 02/01/2021 Revised Sections 1-3; new draft of Section Mike Baum/David
4 Boeker
v0.3 02/03/2021 Revisions in Sections 3-4, new draft of Mike Baum/David
Section 5 Boeker
v0.4 02/05/2021 New drafts of Sections 6-7 on RAID and CR Mike Baum
Management
v0.5 02/09/2021 Revisions in Sections 6-7; new drafts of Mike Baum
Sections 8-9 on Reqs and Dev
Management
v0.6 02/16/2021 Some revisions in Sections 8-9; new drafts Mike Baum
of Sections 10-13 on Document Mgt,
Resource Mgt, Tools and Status and
Internal Communications
v0.7 02/25/2021 Revisions from working sessions during Mike Baum/David
previous week, David R’s suggested edits, Friedman
and initial content for Section 14 Quality
Management Plan
v0.8 02/26/2021 Final draft version for initial formal Mike Baum/David
submission for review and approval Friedman
V0.9 03/10/2021 Revised version based on initial formal Mike Baum/David
review Comments from the State Friedman

03/10/2021
Table of Contents
1. Purpose ............................................................................................................................................................. 10
2. Project Organization ......................................................................................................................................... 11
2.1 Project Operational Chart .......................................................................................................... 11
2.2 Project Team Roles and Responsibilities .................................................................................... 12
2.3 One Washington Program and Technical RACI Matrix............................................................... 16
3. Project Governance Plan .................................................................................................................................. 18
3.1 Governance Framework ............................................................................................................. 18
3.2 One Washington Governance Model ......................................................................................... 22
3.3 One Washington Governance Charts ......................................................................................... 25
3.4 Governance Model Detailed Roles and Responsibilities ............................................................ 26
4. Schedule Management Plan ............................................................................................................................. 38
4.1 Introduction and Purpose .......................................................................................................... 38
4.2 One Washington Program Roadmap ......................................................................................... 38
4.3 Project Schedule Approach and Tools........................................................................................ 39
4.4 Project Schedule Roles and Responsibilities .............................................................................. 41
4.5 Project Schedule Development .................................................................................................. 42
4.6 Project Schedule Maintenance .................................................................................................. 52
4.7 Project Schedule Reporting and Communications..................................................................... 55
5. Cost Management Plan .................................................................................................................................... 58
5.1 Introduction ............................................................................................................................... 58
5.2 Purpose ...................................................................................................................................... 58
5.3 One Washington Budget Background ........................................................................................ 58
5.4 Roles and Responsibilities .......................................................................................................... 59
5.5 Cost Management Approach ..................................................................................................... 60
5.6 Plan Funding Requests ............................................................................................................... 62
5.7 Funding and Budget Development ............................................................................................ 64
5.8 Invoice Processing ...................................................................................................................... 64
5.9 Cost Control and Reporting Processes ....................................................................................... 65
5.10 Agency Pool Funds ..................................................................................................................... 66
5.11 Funding Oversight ...................................................................................................................... 67

03/10/2021
5.12 Technology Budget Changes ...................................................................................................... 68
5.13 Cost Management Glossary of Key Terms ................................................................................. 68
6. RAID Management Plan.................................................................................................................................... 71
6.1 RAID Introduction ....................................................................................................................... 71
6.2 Risk Management....................................................................................................................... 77
6.3 Action Item Management .......................................................................................................... 82
6.4 Issue Management ..................................................................................................................... 83
6.5 Decision Management ............................................................................................................... 88
6.6 RAID Meetings ............................................................................................................................ 94
6.7 RAID Management Glossary of Key Terms................................................................................. 94
7. Scope Management and Change Control Plan ................................................................................................. 96
7.1 Introduction ............................................................................................................................... 96
7.2 Change Control Roles and Responsibilities ................................................................................ 96
7.3 Change Control Guiding Principles ............................................................................................. 98
7.4 Change Control Process ............................................................................................................. 99
7.5 One Washington Change Log ................................................................................................... 102
7.6 Change Control Monitoring and Meetings............................................................................... 103
8. Requirements Management Plan ................................................................................................................... 104
8.1 Requirements Management Overview .................................................................................... 104
8.2 Requirements Management Roles and Responsibilities.......................................................... 105
8.3 Requirements Traceability Approach....................................................................................... 106
9. Development Management Plan.................................................................................................................... 108
9.1 Development Management Overview ..................................................................................... 108
9.2 Development Management Roles and Responsibilities........................................................... 108
9.3 Solution Development Approach ............................................................................................. 110
10. Document Management Plan..................................................................................................................... 115
10.1 Document Management Overview and PMO Responsibilities ................................................ 115
10.2 Document Management Tool .................................................................................................. 115
10.3 Document Management Directory Structure .......................................................................... 115
10.4 Document Management Process ............................................................................................. 116
10.5 Document Naming Standards .................................................................................................. 117

03/10/2021
10.6 Document Management Tool Administration ......................................................................... 119
11. Resource Management Plan....................................................................................................................... 120
11.1 Resource Management Overview ............................................................................................ 120
11.2 Labor Resource Plan ................................................................................................................. 120
12. Project Tools Strategy Plan ......................................................................................................................... 143
12.1 Project Tools Strategy Overview .............................................................................................. 143
12.2 One Washington Project Tools Map and Responsibilities ....................................................... 144
12.3 Project Tools Implementation Plan .......................................................................................... 148
12.4 End-of-Project Tools Plan ......................................................................................................... 148
13. Project Status, Internal Communications and Meeting Management....................................................... 149
13.1 Project Status Meetings ........................................................................................................... 149
13.2 Project Stakeholder Engagement ............................................................................................. 149
13.3 Project Internal Communications ............................................................................................ 150
13.4 Meeting Management ............................................................................................................. 151
14. Quality Management Plan .......................................................................................................................... 155
14.1 Quality Management Overview ............................................................................................... 155
14.2 Quality Management Roles and Responsibilities ..................................................................... 157
14.3 Quality Assurance Plan ............................................................................................................. 157
14.4 Independent QA Reviews with bluecrane ................................................................................ 159
14.5 Deloitte Quality Reviews .......................................................................................................... 159
14.6 Workday Delivery Assurance ................................................................................................... 161
14.7 Quality Control Plan ................................................................................................................. 161
14.8 Quality Monitoring and Reporting ........................................................................................... 167
14.9 Continuous Improvement and Lessons Learned ...................................................................... 167
15. PII Handling ................................................................................................................................................. 169

03/10/2021
Table of Tables
Table 1. Project Team Roles and Responsibilities .................................................................................................... 12

Table 2. One Washington Governance Model Escalation Process and Thresholds ................................................. 23
Table 3. Executive Sponsor Roles and Responsibilities ............................................................................................ 26
Table 4. Executive Steering Committee Roles and Responsibilities ......................................................................... 27
Table 5. Business Transformation Board (BTB) Roles and Responsibilities.............................................................. 28
Table 6. Advisory Committees Roles and Responsibilities ....................................................................................... 31
Table 7. Project Management Office (PMO) Roles and Responsibilities.................................................................. 34
Table 8. Business Owners Roles and Responsibilities .............................................................................................. 35
Table 9. Project Schedule Roles and Responsibilities ............................................................................................... 41
Table 10. Approval Authority for Project Schedule Changes ................................................................................... 42
Table 11. One Washington Project Standard WBS ................................................................................................... 45
Table 12. Project Schedule Fields - Mandatory ........................................................................................................ 50
Table 13. Project Schedule Fields - Optional ............................................................................................................ 50
Table 14. One Washington projects – update parameters ...................................................................................... 53
Table 15. Weekly Project Schedule Update Process ................................................................................................ 53
Table 16. Quality Performance Metrics.................................................................................................................... 57
Table 17. One Washington Budget Background....................................................................................................... 58
Table 18. One Washington Budget and Cost Management Stakeholders Roles and Responsibilities..................... 59
Table 19. Key Performance Metrics ......................................................................................................................... 65
Table 20. RAID Roles and Responsibilities ................................................................................................................ 74
Table 21. Risk Types.................................................................................................................................................. 80
Table 22. Risk Severity Scoring ................................................................................................................................. 81
Table 23. Issue Types that are defined in PMC ........................................................................................................ 86
Table 24. Examples of the types of project decisions .............................................................................................. 90
Table 25. Decision Types .......................................................................................................................................... 93
Table 26. RAID Meetings .......................................................................................................................................... 94
Table 27. RAID Management Glossary of Key Terms ............................................................................................... 94
Table 28. Change Control Roles and Responsibilities ............................................................................................... 97
Table 29. Record and Communicate CR Outcome ................................................................................................. 101
Table 30. CR Statuses in the Change Log ................................................................................................................ 103
Table 31. Requirements Management Roles and Responsibilities ........................................................................ 105
Table 32. Development Management Roles and Responsibilities ......................................................................... 108
Table 33. Workday Solution Security Responsibility Summary .............................................................................. 111
Table 34. Document Naming Standards ................................................................................................................. 118
Table 35. Program Roles and Responsibilities ........................................................................................................ 121
Table 36. State Resources....................................................................................................................................... 135
Table 37. Project Team Training and Skills Acquisition .......................................................................................... 141
Table 39. One Washington Project Tools Map and Responsibilities ...................................................................... 144
Table 40. State In-Scope Tools................................................................................................................................ 146

03/10/2021
Table 42. Project Status Meetings .......................................................................................................................... 149
Table 44. Project Internal Communications ........................................................................................................... 150
Table 45. Meeting Roles and Responsibilities ........................................................................................................ 151
Table 46. Quality Assurance vs. Quality Control .................................................................................................... 155
Table 47. Quality Management Roles and Responsibilities ................................................................................... 157
Table 48. Deloitte Quality Review Plan .................................................................................................................. 160
Table 49. Deliverable Management Roles and Responsibilities ............................................................................. 162
Table 50. DED Components .................................................................................................................................... 163
Table of Figures
Figure 1. One Washington Project Operational Chart.............................................................................................. 11

Figure 2. Sample screenshot cut-out of the One Washington Program and Technical RACI Matrix. ...................... 17
Figure 3. Foundational Governance Framework ...................................................................................................... 18
Figure 4. One Washington Governance Framework ................................................................................................ 20
Figure 5. One Washington Governance Model ........................................................................................................ 22
Figure 6. One Washington Escalation Circuit-breaker Process ................................................................................ 25
Figure 7. One Washington Governance Structure ................................................................................................... 26
Figure 8. One Washington Governance RACI Matrix ............................................................................................... 37
Figure 9. One Washington Modernization Roadmap ............................................................................................... 39
Figure 10. One Washington Standard WBS Dictionary Template ............................................................................ 46
Figure 11. PMC RAID Tool Project Management Benefits ....................................................................................... 71
Figure 12. PMC Release Custom Settings ................................................................................................................. 72
Figure 13. PMC Team Custom Settings .................................................................................................................... 72
Figure 14. PMC Phase Custom Settings .................................................................................................................... 73
Figure 15. PMC Workstream Custom Settings ......................................................................................................... 73
Figure 12. One Washington Risk Process ................................................................................................................. 77
Figure 13. One Washington Action Item Process ..................................................................................................... 83
Figure 14. One Washington Issue Process................................................................................................................ 84
Figure 15. One Washington Decision Process .......................................................................................................... 88
Figure 16. One Washington Prioritization Matrix for Project Decisions .................................................................. 92
Figure 17. One Washington Change Control Process ............................................................................................... 99
Figure 18. One Washington Design and Development Process ............................................................................. 105
Figure 19. One Washington Requirements Traceability Elements ......................................................................... 107
Figure 20. One Washington Configuration and Confirmation Process .................................................................. 110
Figure 21. One Washington Data Conversion Process ........................................................................................... 113
Figure 22. One Washington Workday Solution Integration Framework ................................................................ 113
Figure 23. One Washington Workday Solution Reporting Approach..................................................................... 114
Figure 24. One Washington Program SharePoint Home Page ............................................................................... 115
Figure 25. One Washington Deliverable Process ................................................................................................... 162

03/10/2021
Figure 26. One Washington Continuous Improvement Process ............................................................................ 168

03/10/2021
1. Purpose
The Project Management Playbook (PMP or “Playbook”) documents the structure, processes, and resources that
will be used to plan and execute a successful One Washington implementation. The PMP covers: the project
organization; governance structure; standard project processes and controls; resources and tools; quality
activities and project protocols for onboarding/offboarding, meetings and communications; and refers to the
Information Security and Risk Management Plan (ISRMP) for how to handle personally identifiable information
(PII) on the project.
The Project Management Playbook is approved by the One Washington PMO Manager during the Plan-Imagine
Phase 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 of information about the project’s organization, processes, tools, and
terminology. Once this Playbook has been approved, all new project team members will be indoctrinated in its
practices.
The PMP will be reviewed by the PMO, with input from both the State and Deloitte, at the beginning of each
project phase to confirm its accuracy and completeness. Major, substantive updates to the Project Management
Playbook, particularly regarding governance procedures or other project standard processes or protocols, will
require a change request and must go through the project’s approved change control process, described later in
this PMP.

03/10/2021
2. Project Organization
2.1 Project Operational Chart

Below is the One Washington operational chart as of early February 2021: One Washington Project Operational Chart Link
Figure 1. One Washington Project Operational Chart

03/10/2021
2.2 Project Team Roles and Responsibilities

Below is a table describing the key responsibilities for each of the State-Deloitte project team lead positions
listed in the project organization chart above, as they are defined in the project statement of work (SOW 1A), as
applicable:
Table 1. Project Team Roles and Responsibilities
Project Roles Key Responsibilities
State PMO Manager Leads the One Washington Project Management Office (PMO), managing business
and project management aspects required to deliver the business outcomes of the
project.
Deloitte Project Manager/PMO In accordance with methodologies and standards found in Project Management
Lead Institute's (PMI) Project Management Body of Knowledge (PMBOK® Guide), IT
Infrastructure Library (ITIL) and the Project Delivery Framework, responds to day-to-
day problems, manages issues and risks, provides status reports, participates in
weekly status meetings, develops and timely submits deliverables set forth in the
SOW 1A and manages resources.
Provides input into the project to mitigate risks: Conducts Project Work Plan, Testing
Plan, and Cutover Plan reviews. Performs Operation Readiness Checkpoints –
progressive discussion and updates throughout the One Washington deployment.
Executes day-to-day project operations in collaboration with Deloitte leadership.
Confirms road map aligns with project priorities and business case. Responsible for
managing the project to completion.
Performs a variety of tasks, including: 1) co-developing, managing and maintaining
the Project Work Plan; 2) managing the issue and decision log; 3) setting deadlines
and evaluating Milestones; 4) assigning responsibilities; and 5) delivering status
reports to upper management on a regular basis. Operates as a liaison between
executive management and escalates project issues and risks to the Project Steering
Committee.
Manages the deployment to completion.
Identifies change control issues and highlights.
State Organizational Change Leads the One Washington OCM efforts, directing organizational and stakeholder
Management (OCM) Lead change programs to help transform the State workforce to effectively adopt the new
Workday solution and deliver the business goals of the project.
Deloitte OCM Lead Leads the OCM-focused project activities and integrates them into the overall
project solution deployment strategy.
Defines the OCM work plan across all areas of focus, including communications,
leadership and stakeholder engagement and action planning, end-user training,
organizational alignment, transition, and capability transfer.
Develops the One Washington OCM strategy and manages its successful execution.
Assesses leadership alignment, defines and executes leadership engagement plans.

03/10/2021
Oversees work performed by the change and communications specialists,

organization design specialists, training lead and training developers.
State Finance Lead Coordinates and participates in One Washington design workshops, assists in the
development of business process and role design documents, reviews impact
assessment, and assists in the identification of gaps.
Completes hands-on functional and technical project activities and provides
guidance to State resources for the Financials functional areas in scope.
Demonstrates and explains product features, documents requirements and design,
provides knowledge transfer to the project team, configures the corresponding
functionality, and assists in testing and supporting the roll-out.
Escalates issues and risks, as appropriate.
Deloitte Finance Lead Provides overall leadership and subject matter expertise in the implementation of
the Financials functionality, in-scope functionality and contractual deliverables.
Coordinates and participates in One Washington design workshops, assists in the
Responsible for overall management of the Financials functional team and for the
coordination of their work with the work of other team members/leaders.
guidance to State resources for the Financials functional areas in scope.
Responsible for providing functional expertise for the financials components in
scope. Recommends solutions to One Washington requirements and manages the
design of cross-application solutions.
State Technical Lead Responsible for providing overall leadership and subject matter expertise in the
implementation of the technical areas in scope and overseeing the timely
completion of deliverables required by the Project Work Plan.
Oversees the overall design, testing and deployment of the technical areas.
Responsible for overall management of the Technical functional team and for
ensuring the coordination of their work with the work of other team
members/leaders.
Deloitte Technical Lead Responsible for providing overall leadership and subject matter expertise in the
implementation of the technical areas in scope and overseeing the timely
Oversees the overall design, testing and deployment of the technical areas.

03/10/2021
Responsible for overall management of the Technical functional team and for
ensuring the coordination of their work with the work of other team
members/leaders.
State Data Governance Lead Oversees One Washington data programs and standards.
Provides current State data quality processes and procedures and overall data
quality reports.
Provides oversight to the team to define future State Data Quality Requirements.
Provides input to, reviews and approves Data Cleansing Plan and Data Cleansing
Approaches.
State Architecture Lead Provides subject matter expertise on State technical requirements and standards.
Oversees the overall design of integrations, conversions, and reporting solutions.
Serves as an adviser on complex issues technical issues facing the team.
Deloitte Architecture Lead(s) Drives the overall design of integrations, conversions, and reporting solutions for the
One Washington Workday solution.
Serves as an adviser on complex issues technical issues facing the team.
State Integration Lead Responsible for providing overall leadership in the implementation of the
Integration functionality in scope and overseeing the timely completion deliverables
required by the Project Work Plan.
Responsible for overall management of the Technical Integration functional team
and for the coordination of their work with the work of other team
members/leaders.
Deloitte Integration Lead Responsible for providing overall leadership and subject matter expertise in the
implementation of the Integration functionality in scope and overseeing the timely
Responsible for overall management of the Technical Integration functional team
and for the coordination of their work with the work of other team
members/leaders.
Serve as subject matter advisors on Informatica™ configuration and implementation
for integration.
State Data Conversion Lead Coordinates and participates in One Washington design workshops and assists in the
development of conversion data mappings.
Responsible for overall management of the conversion team and for the
coordination of their work with the work of other team members/ leaders.
Responsible for converting data from the existing system into Workday’s data
objects. Assists conversion team in resolving any source data or mapping errors.
Provides leadership and subject matter expertise in State requirements for data
extracts, transformation and cleansing and oversees the timely completion of
Deliverables required by the Project Work Plan.

03/10/2021
Deloitte Data Conversion Lead Responsible for providing overall leadership and subject matter expertise for One
Washington conversion to Workday and overseeing the timely completion of
Deliverables required by the Project Work Plan.
Coordinates and participates in One Washington design workshops and assists in the
development of conversion data mappings.
Responsible for overall management of the conversion team and for the
coordination of their work with the work of other team members/ leaders.
Responsible for converting data from the existing system into Workday’s data
objects. Assists conversion team in resolving any source data or mapping errors.
Serve as subject matter advisors on informatica™ configuration and implementation
for conversions.
State Reporting Lead Responsible for providing overall leadership and subject matter expertise for State
Workday reporting requirements and overseeing the timely completion of
deliverables required by the Project Work Plan.
Coordinates and participates in State design workshops and assists in the
development of Reports mappings.
Responsible for overall management of the reporting team and for ensuring the
Deloitte Reporting Lead Responsible for providing overall leadership and subject matter expertise for State
Workday reporting requirements and overseeing the timely completion of
deliverables required by the Project Work Plan.
Coordinates and participates in State design workshops and assists in the
development of Reports mappings.
Responsible for overall management of the reporting team and for ensuring the
State Test Lead Responsible for coordinating testing efforts that validate State project deployments.
Works with the Subject Matter Experts (SMEs) to develop the test strategy and test
plans, identify test requirements, create test scenarios, and oversee the execution of
the test scenarios.
Deloitte Test Lead Develop the Testing Strategy deliverable with the State and guide its review and
approval process.
The test manager is responsible for planning, managing, directing, and coordinating
the test phase of the project.
State Security Lead Responsible for providing leadership support and subject matter expertise in the
implementation of the User Security functionality in scope and overseeing the timely

03/10/2021

guidance to State resources for the Security functional areas in scope.
Deloitte Security Lead Responsible for providing leadership support and subject matter expertise in the
implementation of the User Security functionality in scope and overseeing the timely
guidance to State resources for the Security functional areas in scope.
2.3 One Washington Program and Technical RACI Matrix

The One Washington Program and Technical RACI (Responsible, Accountable, Consulted, and Informed) Matrix is
available and maintained here on the One Washington SharePoint site: Program and Technical RACI. The
Program and Technical RACI Matrix spreadsheet includes an Instructions tab, functions glossary tab (describing
the RACI Function areas/columns), and a version history tab for the RACI.
Per the sample below, the RACI can be filtered by State Agency, Category (i.e., Business or Technical), Role and
Name (First and Last Name), so a user can get a summary of the One Washington functions where each
role/person is responsible, accountable, consulted, or informed.
The Program and Technical RACI Matrix is maintained by the One Washington Project Management Office
(PMO).

03/10/2021
Figure 2. Sample screenshot cut-out of the One Washington Program and Technical RACI Matrix.

03/10/2021
3. Project Governance Plan

Per the SOW 1A for this project, the ability to identify issues needing decisions, evaluating options, making
recommendations, gaining leadership agreement on recommendations and communicating modifications is
critical to One Washington success.
Deloitte will help the State PMO define and execute effective project governance aligned with standard project
management principles. Deloitte’s Project Management Center (PMC) tool will be used to document and
manage project risks, action items, issues, and decisions (RAID) to closure throughout the life of the project.
3.1 Governance Framework

The One Washington Program Governance Management Plan is based upon the Project Management Institute’s
(PMI) project governance methodology, tailored to support the unique characteristics of the One Washington
program. Three key principles of the PMI governance framework are:
1. “Implementation of the project governance framework should be based on the context of the
organization and project. There is no one governance framework that is effective for all situations”
2. “Project governance should establish transparency and confidence in decision making and clarify roles
and responsibilities”
3. “Project governance should involve the least amount of authority structure possible because time and
costs are associated with governance decision-making and oversight activities”
The diagram below sets the stage for the relationships between the One Washington Governance Teams and the
project management team:
Figure 3. Foundational Governance Framework

03/10/2021
3.1.1 Governance Guiding Principles

The purpose of this governance structure is to set the responsibilities and practices exercised by the governance
bodies to provide strategic direction, ensure that objectives are achieved, appropriately manage risks and
change, and ensure good stewardship of State resources. In order to achieve this purpose, the following
principles must be applied at all levels of governance escalation and decision making:
1. First and foremost, the One Washington program is a business transformation aimed at increasing
efficiencies, standardization and transparency. Business decisions are linked to strategic goals and are
sustainable for delivering value and benefits to the State.
2. Decisions are made based upon the long-term interests of the enterprise, are fact-based, quantifiable (to
the extent possible) and driven by business need.
3. Decisions are made at the lowest level possible, taking into account the full stream of business,
technology and people needs, including:
a. The knowledge that defines the business;
b. The information necessary to operate the business;
c. The technologies necessary to support the business operations;
d. The people necessary to apply technology towards business operations; and
e. The overall processes necessary for implementation, maintenance and sustainment.
4. Decisions balance advocacy and control. Advocacy for interest, buy-in and investment by stakeholders is
balanced by ensuring a robust business and technology infrastructure, as well as program oversight.
5. Diversity and inclusion in decision making will account for multiple perspectives, including agencies, IT,
human resources, risk, budget and environmental constraints and opportunities.
6. Adherence to data and information security, accessibility, and privacy standards consistent with industry
standards, federal and State law, and OCIO policy must be ascertained when applicable to a decision.
7. Decisions will seek to leverage common practices across agencies and limit variation to the extent
possible and to continuously align business processes. Configuration is prioritized over customization
within and across all business functions.
8. Decisions will seek to prepare State staff to successfully navigate and adopt the new tools and business
processes meaning organizational change management must be applied at every step, stage and
crossroad.
9. Decisions take into account three important aspects:
a. The pursuit and opportunity for future State growth and innovation
b. The cultivation of strong, effective enterprise-wide relationships
c. The fostering of inter-business linkages, alignment and integration
10. Revision of the governance structure will occur when scope, schedule and budget is adjusted or as
deemed necessary by the executive sponsor, executive director or program director. Revisions will
include members of the governance structure and other stakeholders, as necessary.
3.1.2 One Washington Project Governance Framework

The One Washington governance framework aligns with the structure of the organization, enabling efficient
communication of status, risks, issues, change orders, deliverables and other information to support effective
monitoring, performance evaluation, and decision making by the governing bodies.
Based on Legislature-appropriated funding and subsequent decisions by the Executive Steering Committee, the
program defined the following phased approach:

03/10/2021
1. Replace Agency Financial Reporting System (AFRS) and core financial functionality including a new chart
of accounts, general ledger and a standard cost allocation system making the new Enterprise Resource
Planning (ERP) the official system of record by July 2022
o ERP software selection by Feb 2020 – selection was Workday
o System integrator selection by May 2020 – selection was Deloitte
2. Establish a new Medicaid reimbursement cost allocation system by July 2022
3. Replace the accounts receivable system with the new ERP by July 2022
4. Implement expanded financial and procurement functions, replacing WSDOT Trains, into the Workday
ERP by July 2023 (this will include functionality not presently available)
5. Implement HR/payroll and budget preparation into the Workday ERP by July 2025
The governance framework below was approved by the Executive Steering Committee in August 2019:
Figure 4. One Washington Governance Framework
The One Washington governance model leverages statewide functional business owner expertise, partnership,
support and leadership at all levels of governance.
3.1.3 One Washington Governance Framework Level Descriptions

The governance bodies presented in the One Washington Governance Framework in Figure 3 above are further
defined below. More specific details regarding the Roles and Responsibilities for each governance body and
sample types of project issues they may address can be found in section 3.4.
Executive Sponsor: The executive sponsor is the single point of authority and accountability for the program and
has authority to make decisions on any matter escalated by the ESC or executive director. Most decisions are
expected to be made by subordinate governance bodies.

03/10/2021
Executive Steering Committee (ESC): The executive steering committee establishes the overall priority and
direction for the program. The ESC sets strategic direction and has authority to make decisions on the program’s
scope, schedule and budget, as well as matters escalated by the executive director, program director, business
transformation board, advisory committees, business owners, or project management office.
Business Transformation Board (BTB): The BTB board has authority to make decisions regarding statewide
planning, implementation, and operation of the program, so long as those decisions do not change critical
program phase scope, schedule, or budget. The BTB has authority over change orders that do not change critical
scope, schedule or budget. BTB has authority over risk mitigations, issue resolutions, or any other matters that
impact the One Washington program at the operational and enterprise level. The BTB makes operational
decisions with a multi-agency level impact to overall business function(s) of the State. BTB establishes cross-
agency strategy and alignment, as well as cross-business-function (i.e., finance, HR, payroll, budget, and
procurement) and cross-program-function (i.e.: OCM, data, technology) strategy and alignment.
Advisory Committees (AC): Within the scope of their authority of the specific business or program function, the
advisory committees are authorized to make decisions on matters related to the business function and/or area
of expertise as well as deliverables, requirements, business capabilities, change orders, risk mitigations, issue
resolutions, or any other matter regarding delivery of enterprise business and functional capabilities to program
stakeholders. Advisory committees have authority over business and technical planning, implementation and
operational decisions. Advisory committee decisions focus on improving the alignment and integration of
business function processes across the enterprise.
Project Management Office (PMO): With support from the business owners, the PMO has authority over core
and day-to-day operations of the project and program. The PMO will triage matters escalated by the program’s
functional teams and has authority to make decisions on matters regarding the planning, coordination, direction,
control, and reporting tasks/activities to complete the program’s scope of work within the parameters of the ESC
and BTB.
Business Owners: The business owners are essential to program success.1 They know their customers and how
best to work with them. Business owners play a unique and critical role that allows them access and mobility
within several groups of the governance structure. Business owners attend and provide information, as needed
to ESC members. Business owners are voting members of the BTB and chair an Advisory Committee that
corresponds to their business function. Business owners have authority to make decisions regarding program
readiness and agency readiness for their respective business areas. There are main business owners and sub-
business owners, as defined in the details below. The business owners have a unique decision-making position
because they support all levels of governance.
1
One Washington is committed to empowering business owners to lead the state to a different way of doing business. In this
way, impacted stakeholders will have confidence that the leaders they currently look to for guidance on a host of policy
questions are the true “owners” of any future solution. This strategic decision will reduce resistance, increase trust across the
enterprise and put the One Washington effort on a path to sustainable results.

03/10/2021
Workstreams/Team Leads: The workstream/team leads are responsible for a subset of the overall project team
and accountable for managing their respective team staff and producing high-quality work products. The
workstreams/team leads help the project manager plan, monitor, and control the project work, and are
responsible activities and products of their project teams, including detailed work planning, staff selection and
management, project team training, status reporting, and management of project controls (i.e., risks, issues,
action items, decisions, and change requests) pertaining to their team and/or workstream.
3.2 One Washington Governance Model

As defined in the One Washington Governance Plan Version 2.0, the program has a five-tier governance
structure for escalation of decisions or other project items that follows the guidelines described below:
Figure 5. One Washington Governance Model
3.2.1 One Washington Governance Model Escalation Process and Thresholds

An escalation level threshold is the value of the decision-making variable at which the decision is made, such that
an action is selected marking the end of the outstanding decision or project item. Decisions that require an
accumulation of information and research should be properly and fully documented in Project Management
Center (PMC, for RAID items) or the One Washington Change Request (CR) Form and ready for the governance
entity to review the item with the adequate information and recommendations to make a final decision.
In alignment with the guiding principle “Decisions are made at the lowest level possible,” escalation should be
the exception, not the rule. In addition, given the ability to quickly change Workday configurations during Phase
1A Design and Build activities, the goal is to get escalated items resolved no later than fifteen (15) working days
from the initial escalation date.

03/10/2021
The table below describes the Escalation Process and Thresholds for each level of the One Washington
Governance structure:
Table 2. One Washington Governance Model Escalation Process and Thresholds
Level Escalation Process Thresholds / Criteria

One Washington Escalation 0: Team Members escalate RAID Project controls will be escalated to the
Workstream items to their respective Workstream Lead Workstream Lead when:
Teams and Team (e.g., Finance, HCM, OCM, etc.) through  The RAID item impacts the workstream
Leads regular, day-to-day interactions. Escalation only and does not require input or
level in PMC for RAID items is left blank. involvement from other workstreams
 The CR impacts the workstream only
and does not impact the Phase 1A
scope, schedule or budget
One Washington Escalation 1: Workstream leads escalate RAID items and CRs will be escalated to the PMO
PMO RAID items to the PMO by changing the when:
escalation level in PMC to 1, or submit CR to
PMO for discussion in next status meeting,  The RAID item cannot be resolved by
or schedule a meeting if urgent and status Workstream Teams, and the RAID priority is
meeting is more than 2 days away. not Low
 The RAID item impacts multiple project
teams, or the resolution requires coordination
across teams
 The CR will impact Phase 1A scope,
schedule or budget < 5%
Advisory Escalation 2: PMO Manager escalates RAID RAID items and CRs will be escalated to the
Committees item to the appropriate Advisory Advisory Committees when:
Committee(s) by changing the escalation
level in PMC to 2, or sharing CR and setting  The RAID item cannot be resolved by PMO
up a meeting with proper participants to working with the appropriate Workstream
discuss within two working (2) days of Team Leads, and the RAID priority is not Low
escalation, with aim of resolving item in 4-5  The CR will impact Phase 1A scope,
working days. schedule or budget < 7.5%
Business Escalation 3: The Advisory Committee RAID items and CRs will be escalated to the BTB
Transformation Chair(s), will determine when RAID items or when:
Board (BTB) CRs need to be escalated to the BTB; and
when escalated, will receive process  The RAID item cannot be resolved by PMO
support from the PMO. working with the appropriate Advisory
Committees, and the RAID priority is not Low
To escalate a RAID item or CR to the BTB,
the PMO will work under the direction of  The CR will impact Phase 1A scope,
schedule or budget < 10%
the appropriate Chair(s) to:
1. Change the escalation level for the
RAID item in PMC to 3
2. Confirm that the RAID
documentation in PMC or CR form
is accurate and complete
3. Send the RAID item or CR with
recommendation(s) to the BTB

03/10/2021
Level Escalation Process Thresholds / Criteria

4. Set up a meeting with BTB to
discuss within two (2) working days
of escalation, with aim of resolving
item in 2-3 working days
Executive Escalation 4: The BTB Program Director, in RAID items and CRs will be escalated to the ESC
Steering conjunction with the PMO Manager and when:
Committee (ESC) any impacted Advisory Committee Chair(s),  The RAID item cannot be resolved by PMO
will determine when RAID items or CRs working with the BTB and appropriate
need to be escalated to the ESC. Advisory Committees, and the RAID priority
is not Low
To escalate a RAID item or CR to the ESC,
the PMO will:  The CR will impact Phase 1A scope,
schedule or budget > 10%
recommendation(s) to the ESC
4. Set up a meeting with ESC to
discuss within two (2) working days
of escalation, with aim of resolving
item in 1-2 working days
Executive Escalation 5: The ESC Executive Director, in RAID items and CRs will be escalated to the ESC
Sponsor conjunction with the PMO Manager, BTB when:
Program Director and any impacted  The RAID item cannot be resolved by PMO
Advisory Committee Chair(s), will working with the ESC, BTB and appropriate
determine when RAID items or CRs need to Advisory Committees, and the RAID priority
be escalated to the Executive Sponsor. is not Low
To escalate a RAID item or CR to the  The CR will impact Phase 1A scope,
schedule or budget > 10%
Executive Sponsor, the PMO will:
recommendation(s) to the
Executive Sponsor for final
decision
4. Set up a meeting with Executive
Sponsor to discuss within two (2)
working days of escalation, with
aim of resolving item in 1-2
working days

03/10/2021
3.2.2 One Washington Escalation Circuit-breaker Process

Incorporated into the governance and decision-making model is a “circuit-breaker” process. The circuit-breaker
process is intended to circumvent the One Washington standard escalation process when the level of priority
and urgency does not allow for the time needed to follow the standard escalation protocols.
The circuit-breaker process can be invoked by the executive sponsor or designee, working with the PMO
Manager, in the event of an impasse on a decision or when an issue requires an immediate decision not allowing
time to assemble the entire ESC. Upon notification from the executive director or program director, the
executive sponsor or designee would identify key ESC and/or BTB members who would be assembled to hear
positions on the project issue and make a decision.
A circuit-breaker event will always include the business owner(s) or delegate for the business area of the issue or
impasse, and the PMO Manager. The diagram below illustrates the circuit-breaker process and its ability to fast-
path a project item or CR to the ESC/Executive Sponsor level when needed:
Figure 6. One Washington Escalation Circuit-breaker Process
3.3 One Washington Governance Charts

3.3.1 Governance Membership Chart
The One Washington full governance membership may be viewed at One Washington SharePoint Governance
Charts.

03/10/2021
3.3.2 One Washington Governance Structure

The figure below illustrates the specific One Washington Project Governance Structure that will be in place
throughout the Workday implementation project (detailed roles and responsibilities follow in the next sub-
section):
Figure 7. One Washington Governance Structure
3.4 Governance Model Detailed Roles and Responsibilities

The tables below details the membership and responsibilities of each group within the One Washington
Governance Model. At the end of this section, there is a Governance RACI Chart that provides additional context
regarding the responsibilities for the group for Phase 1A of the project.
3.4.1 Executive Sponsor Roles and Responsibilities

Table 3. Executive Sponsor Roles and Responsibilities
Executive Sponsor
Authority The executive sponsor is the single point of authority and accountability for the program
and has authority to make decisions on any matter escalated by the ESC or executive

03/10/2021
director. Most decisions are expected to be made by subordinate governance bodies;

therefore, few decisions are anticipated to be made by the executive sponsor. The
executive sponsor may select a designee to act on his/her behalf.
Roles and  Chairs the ESC

Responsibilities  Resolves items escalated by ESC or executive director
 Oversees the circuit-breaker process
Performance and  Regular briefings by executive director

Oversight  Monthly ESC meetings including program performance measures
Controls
 Monthly reports from quality assurance
 Recommendations from the Office of the Chief Information Officer
3.4.2 Executive Steering Committee Roles and Responsibilities

Table 4. Executive Steering Committee Roles and Responsibilities
Executive Steering Committee (ESC)

Chair Executive Sponsor Patricia Lashway, OFM Deputy
(Note: The executive director and program director will create and present the ESC
briefing materials; meetings are the second Wednesday of the month.)
Charter was signed 12/12/18 and resides on the One Washington SharePoint site in the
PMO site under Project Management Plans -->Charters.
Voting and Ex- See the One Washington Governance Membership Chart
officio Members
Membership Members are appointed by the executive sponsor. The executive sponsor has full
selection authority to appoint and remove members to ensure the success of the program.
Additional ESC  OCIO oversight partners

Meeting  External quality assurance (QA) consultants
Participants
 Executive director
 Program director
 Business owners
 OFM and DES IT leaders
 PMO and One Washington staff
 As needed, other program participants/stakeholders to support issues and
agenda items to be discussed at ESC meetings
Authority The ESC has authority to make decisions on scope, schedule, and budget as well as
matters escalated by the BTB, executive director, program director, and/or business
owners.

03/10/2021
Decision-making 1. Discussion of the recommendations put forward by the One Washington
process program.
2. Dissenting opinions on the recommendations are identified and discussed
followed by the executive sponsor’s approval. Silence is consent.
Quorum Consensus in decision making is preferred. Voting is by simple majority, with the
executive sponsor breaking any tie. Half (5) of the members of the committee must be
present, in person or via mobile participation, to constitute a quorum. Recommendation
decisions are a simple majority vote.
Roles and  Actively participate in ESC meetings

Responsibilities  Approve ESC group charter and revisions
 Approve the program charter and program governance deliverables
 Approve change orders that impact critical path schedule, scope and budget
 Approve project closure or termination
 Approve recommendations for risks and issues escalated by the program
director, BTB, business owners, advisory committees, or PMO
 Provide oversight of program performance
 Provide guidance to ensure alignment with strategic objectives
 Provide leadership in enforcing, carrying out, and/or communicating decisions
 Approve project closure and termination
 Provide guidance to ensure alignment with strategic objectives
 Provide leadership in enforcing, carrying out and/or communicating decisions
Performance and  Monthly executive director’s ESC briefing including program performance
Oversight measures
Controls  Monthly reports from quality assurance consultant
Stakeholder Agency leaders are expected to involve and inform all relevant parties in their agencies
communication and/or the agencies they represent.
responsibility
3.4.3 Business Transformation Board (BTB) Roles and Responsibilities

Table 5. Business Transformation Board (BTB) Roles and Responsibilities
Business Transformation Board

Chair Matthew Meacham, Office of Financial Mgmt. One Washington Program Director
(Note: The program director will create and present BTB agenda and briefing materials;
meetings are the last Wednesday of the month)
Charter was signed 7/31/2019 and resides on the One Washington SharePoint site in the
PMO site under Project Management Plans -->Charters.
Voting members Please see the One Washington Governance Membership Chart

03/10/2021
Membership  Make-up: 10-15 members total; membership will be diverse in agency size,
selection complexity and how they perform business
 Selection: Application for a seat on the BTB will be reviewed by the program
director. After initial review, requests will be forwarded to the enterprise domain
business owner. After approval, the member will receive an invitation from the
Program with a copy of the charter.
 Duration: Program director or designee will designate permanent/tenured and
non-permanent/rotating membership.
o Permanent membership is based on the agency position
o Non-permanent members will rotate, add or de-select as needed based
on business and program needs. Members will remain on the BTB for 12-
24 months. Participation will be staggered so that memberships overlap
ensuring that new members and existing membership overlaps. Rotating
with new members will ensure new perspectives, long-term perspectives
and reducing group biases.
 Delegation: The program director or designee determines when delegates are
allowed and will indicate that in the meeting agenda. If delegates are allowed,
members may delegate someone to attend on their behalf with the expectation
that:
o Delegates must be introduced electronically in advance of the meeting
and must be approved by the program director 24 hours before the
meeting takes place.
o The delegate must have the same level of knowledge and skill as the
member.
o The delegate must be fully educated by the member they represent
before attending any meeting.
o The committee will not repeat or review prior discussions or decisions.
o The delegate has full authority to make decisions on behalf of the
member.
o If a member cannot attend in person or phone and they do not have a
delegate that meets these requirements, members may send a note-
taker who will silently take notes but not vote, interrupt, interject or
otherwise take part in the meeting.
Cessation: Membership may be terminated by the program director for any reason at any time.
Members must have an enterprise view of the program and not stick to their own agency
perspective. Members must support the program work and healthy discourse.
Additional  External quality assurance (QA) consultant

Participants  PMO and One Washington staff
 Other program participants/stakeholders to support issues and agenda items, as
needed
Authority  The BTB is authorized to make high-level operational decisions that impact the
program and agencies; scope of decisions should be enterprise-wide across
agencies and business functions.

03/10/2021
 The BTB is authorized to make decisions and recommendations on matters

escalated by the advisory committees, PMO and/or program director.
 The BTB has authority to make decisions regarding program deliverables,
requirements, business capabilities, change orders, risk mitigation, issue
resolutions, or any other matter regarding delivery of enterprise business and
functional capabilities to program stakeholders when these areas reside within
the scope, schedule and budget and do not impact the program critical path.
The BTB does not have authority to:
 Make decisions on matters impacting ESC performance measures
 Make decisions on matters impacting critical path Phase 1A scope, schedule or budget
Decision-making 1. Discussion of the recommendations put forward by the One Washington program or
process advisory committees.
2. Dissenting opinions on the recommendations are identified. A motion is put forth
followed by a vote of the members.
3. Action steps based on that decision are then identified and assigned.
Quorum Voting will be by simple majority, with the program director breaking any tie. In order to
conduct a vote on any proposal, three quarters (11) of the voting members of the board
must be present, in person or via mobile participation, to constitute a quorum.
Recommendation decisions are simply majority vote.
Roles and  Promote continuous alignment of the program’s strategic objectives, timelines,
Responsibilities and business processes
 Review and consider redesign and/or standardization of existing business
processes
 Function as program leaders and provide strategic leadership for enterprise
conversations, discovery, understanding, and collaboration with business
stakeholders on such topics as: business capabilities, change management, risk
and issue management, testing, lessons learned and continuous improvement
 Approve and propose to the ESC any recommended changes to the BTB Charter
 Recommend changes to the ESC on project management plans: e.g., RAID,
Change Control, etc.
 Approve project deliverables
 Review and advise performance measures/metrics
 Champion desired outcomes and capabilities in partnership with the program,
and advocate for successful adoption within the agency community
 Implement or recommend program strategies to the ESC for consideration
 Monitor program plans for enabling business function strategies
 Review external assessments and benchmarking activities
 Review business continuity capabilities, including vendor disaster recovery plans
 Review and provide resource and issue recommendations to the ESC
 Review and provide scope, schedule or budget recommendations to the ESC that
are outside of BTB responsibilities

03/10/2021
 Share pertinent information and obtain feedback from other agency leaders
and/or departments, stakeholders, and sub-business process owners; bring
feedback and information from these stakeholders to the decision-making
process
 Involve relevant sub-business owners and other agency leaders, as needed
Performance and  Monthly program director’s BTB briefing, including program performance
Oversight measures
Controls  Monthly reports from quality assurance

Stakeholder  Business owners are expected to involve other sub-business owners: e.g., HR
communication may include leaders of HCA, DRS and DES, as needed
responsibility  Agency leaders are expected to involve and inform all relevant parties in their
agencies and/or the agencies they represent, as well as agencies who may be
impacted
3.4.4 Advisory Committees Roles and Responsibilities

Table 6. Advisory Committees Roles and Responsibilities
Advisory Committees
Chair Business owners for finance, procurement, budget, HR and payroll
One Washington staff for OCM, technical and data governance
(Note: The chairperson sets the agenda for the monthly meeting and with support from
the PMO will create and present the meeting materials.)
Charters will reside on the One Washington SharePoint site in the PMO site under Project
Management Plans -->Charters.
Members See the One Washington Governance Membership Chart

 Statewide business function leaders and operations subject matter experts
providing strategic leadership to ensure the stakeholder expectations for
enterprise’s business and functional capabilities will be met
 Permanent membership is based on the agency
 Non-permanent membership is based on the skill and experience
Membership  1 Chairperson/facilitator
 Makeup: 10-15 members total; membership will be diverse in agency size,
complexity and how they perform business
 Selection: Members must apply via an email to the One Washington program
director and/or the chairperson with an explanation of their skills and experience
as well as their agency support of the program. The chairperson has authority to
approve/disapprove membership and will do so with the input of the program
director.

03/10/2021
 Duration: Chair will designate permanent and non-permanent

o Permanent membership is based on the agency position
o Non-permanent members will rotate, add or de-select as needed based
on business and program needs
o Members will remain on the advisory committee for 12-24 months
o Participation will be staggered so that memberships overlap, ensuring
that new members and existing membership overlaps
 Rotating with new members will ensure new perspectives, long-
term perspectives and reducing group biases
 Delegation: The chairperson determines if delegates are allowed; if delegates are
allowed, members may delegate someone to attend on their behalf with the
expectation that:
o Delegates must be introduced electronically in advance of the meeting
and must be approved by the chairperson 24 hours before the meeting
takes place
o The delegate must have the same level of knowledge and skill as the
member
o The delegate must be fully educated by the member they represent
before attending any meeting
o The committee will not repeat or review prior discussions or decisions
o The delegate has full authority to make decisions on behalf of the
member
o If a member cannot attend in person or phone and they do not have a
delegate that meets these requirements, members may send a note-
taker who will silently take notes but not vote, interrupt, interject or
otherwise take part in the meeting
 Cessation: Membership may be terminated by the chairperson for any reason at
any time. Members must have an enterprise view of the program and not stick to
their own agency perspective. Members must support the program work and
healthy discourse.

Authority  Responsible to ensure agency readiness for all stages of program planning and
implementation
 Authorized to make decisions on matters within the subject matter expertise of
their function or program operations such as deliverables, requirements,
business capabilities, change orders, risk mitigations, issue resolutions, or any
other matter regarding delivery of enterprise business and functional capabilities
to program stakeholders
 Write issue papers and make recommendations to the BTB
Decision-making 1. Discussion of the recommendations put forward by the chairperson, the One
process Washington program or advisory committee members.
2. Dissenting opinions on the recommendations are identified. A motion is put forth
followed by a vote of the members.
3. Action steps based on that decision are then identified and assigned.

03/10/2021
Quorum  Voting will be by simple majority, with the chairperson breaking any tie. Half of the
members of the committee must be present, in person or via mobile participation, to
constitute a quorum.
 Recommendation decisions are simply majority vote.
Roles and  Vet issues, analyze business priorities and propose enterprise-level
Responsibilities recommendations for program action; Committee outputs will be routed to the
next level up in the current Program organizational structure
 Be knowledgeable of the Program Blueprint and strategy documents and
promote continuous alignment of the committee’s activities with the Program’s
strategic objectives, timelines and processes
 Function as an agency business liaison, and provide strategic leadership for
enterprise conversations, discovery, understanding, and collaboration with
agency business stakeholders, on such topics as business capabilities, change
management, risk and issue management, testing, lessons learned and
continuous improvement, review and validation of performance
measures/metrics
 Champion desired outcomes and capabilities in partnership with the program,
and advocate for successful adoption within the agency community, both
discretely and broadly
 Secure or solicit volunteer resources, when needed
 Depending on committee, approve business capabilities and/or technical
requirements, including any future updates
 Approve recommendations for risks and issues escalated by the PMO
 Provide guidance to ensure delivery of technical requirements and business
capabilities meet the expectations of program stakeholders
 Provide leadership in enforcing, carrying out, and/or communicating decisions
 If a project issue (e.g., RAID or CR ticket) is escalated to the BTB, a member of the
Advisory Committee must:
o Request the topic be added to the BTB agenda
o Send corresponding information and/or recommendations to the BTB via
an issue paper (and/or reference to RAID item in PMC, where
appropriate)
o Attend the BTB to explain, discussion and obtain decision
o Report back to the Advisory Committee the BTB decision/action
 Creating focused-task sub-groups and sub-committees around program and/or
agency readiness
 Inform the BTB and the One Washington program of any major decisions
Performance and Chairperson is responsible for ensuring documentation of the meetings (this can be
Oversight delegated) that includes:
Controls  Attendees
 Agenda
 Highlights and decisions

03/10/2021
 Action items with dates and leads

Meeting notes and decisions will be stored on the One Washington program SharePoint
site.
Stakeholder Involve and inform leaders and subject matter experts for all relevant parties in their
communication respective agencies and/or the agencies they represent as well as agencies who may be
responsibility impacted.
3.4.5 Project Management Office (PMO) Roles and Responsibilities

Table 7. Project Management Office (PMO) Roles and Responsibilities
Project Management Office

Authority The PMO will triage matters escalated by the project’s workstream teams, and has
authority to make decisions on matters regarding the planning, executing, and reporting
tasks/activities to complete the project’s scope of work within the parameters of the
program performance measures.
The PMO does not have authority to:

 Make decisions that impact the critical path for Phase 1A scope, schedule or
budget
 Make decisions outside of current business function policies
Roles and  Prepare briefings and reports for ESC and BTB meetings
Responsibilities  Develop charters for both ESC, BTB and advisory committees
 Work with the BTB to develop program performance measures
 Develop project management plans and processes for the program
 Ensure compliance with established program processes (e.g. issue, risk, and
requirements management)
 Plan program tasks/activities to meet program objectives and program
performance measures
 Ensure accurate project reporting
Performance and  Briefings and reports from ESC, BTB and advisory committees
Oversight  PMO reports of performance and quality
Controls
 Feedback from the executive sponsor, executive director, program director, ESC,
BTB and advisory committees
 Reports from the quality assurance consultant
Stakeholder Communicate with all stakeholders through all branches of State government, including
communication higher education as appropriate.
responsibility

03/10/2021
3.4.6 Business Owners Roles and Responsibilities

Table 8. Business Owners Roles and Responsibilities
Business Owners
Members: See the One Washington Governance Membership Chart
statewide business owners for finance, procurement, budget, HR and payroll
Additional  External quality assurance (QA) consultant

Participants  Additional business owners in finance, HR/payroll, budget, procurement
and/or IT
 PMO and One Washington staff
 Other program participants/stakeholders to support issues and agenda
items, as needed
Authority  Provide strategic leadership to ensure the stakeholder expectations for

enterprise’s business and functional capabilities will be met
 The business owners are authorized to make unilateral decisions within
their respective business function(s)
 The business owners do not have authority to make decisions on matters
impacting Phase 1A critical path scope, schedule, or budget
 The business owner group is not technically a decision-making body within
the One Washington governance structure, but they have authority as part
of their position in their respective line of business
 A business owner may select a designee to act on his/her behalf
Decision-making There is no formal decision-making process: Issues must either go to the BTB or an
process advisory committee or be handled within the authority of the business owner.
Roles and  Actively participate and provide information and issues at the ESC
Responsibilities meetings
 Act as a voting member of the BTB meetings
 Chair or provide a delegate to chair an advisory committee
 Approve advisory committee charters
 Approve and manage membership of an advisory committee
 Approve project management plans (e.g. issue, risk, etc.) and project
deliverables
 Approve technical requirements and business capabilities, including any
future updates
 Approve recommendations for risks and issues escalated by the program
or project management
 Provide guidance to ensure delivery of technical requirements and
business capabilities meet the expectations of program stakeholders
 Provide leadership in enforcing, carrying out, and/or communicate
decisions

03/10/2021
Performance and Please see the BTB and Advisory Committee details.
Oversight
Controls
Stakeholder  Business owners are expected to involved other sub-business owners (e.g.,
communication HR may include leaders of HCA, DRS and DES), as needed, as well as
responsibility agencies who may be impacted.

03/10/2021
3.4.7 Governance RACI Matrix
The comprehensive One Washington Governance RACI Matrix as of January 2021 is pasted below. It is maintained by the One Washington PMO.
Figure 8. One Washington Governance RACI Matrix

03/10/2021
4. Schedule Management Plan
4.1 Introduction and Purpose

Developing a project schedule is “the process of analyzing activity sequences, durations, resource requirements
and schedule constraints to create the project schedule model for project execution and monitoring and
controlling” (PMBOK® Guide, 6th Edition).
The One Washington program is a complex business transformation and modernization effort to replace aging
statewide enterprise systems with a modern enterprise resource planning (ERP) system. “A program is defined as
related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain
benefits not available from managing them individually…” (The Standard for Program Management, 4th Edition).
This project spans budget cycles of multiple biennia. It is under both OCIO oversight and quality assurance
services provided by a third-party contractor.
The size and complexity of this project will demand close attention to the program’s master schedule. This is
particularly important to maintain the quality of deliverables and to avoid project slippage by closely monitoring
tasks and key milestones.
4.2 One Washington Program Roadmap

The One Washington Program Roadmap is a chronological representation of the program’s intended direction
and graphically depicts major milestones and events. The roadmap illustrated below was developed to align with
the program’s investment plan and depicts how the implementation of the new ERP (Workday) system will
deliver system capabilities through incremental releases over the next four years.

03/10/2021
Figure 9. One Washington Modernization Roadmap
The schedule management plan provides guidance on how the One Washington PMO will develop, manage and
control the schedule throughout the lifecycle of the program. The plan defines:
 The program approach to schedule management. This will provide the basis for developing the overall
structure of the schedule.
 Roles and responsibilities for tracking and reporting schedule progress, including who is responsible for
tracking and reporting schedule progress and the frequency of these updates.
 The processes and tools used for schedule management, including the preferred level of granularity for
tasks and mandatory schedule components to allow for proper monitoring and status reporting.
 How the schedule will be baselined and how approved changes will be incorporated.
 Status metrics and reporting needs, used to illustrate progress and determine variances.
 The distribution, storage, version control and access to both the schedule management plan and the
master project schedule.
Please Note: This management plan was built around the need for flexibility and provides the ability to adapt to
changes quickly. It aims to avoid being too prescriptive in schedule management.
4.3 Project Schedule Approach and Tools

4.3.1 Project Schedule Scope
The One Washington program encompasses several workstream efforts that are being managed as separate but
related sub-projects. Each of these projects will follow this schedule management process and be incorporated
into a project schedule. The project schedule is an integrated program planning document that defines individual
workstream activities and timelines, but also program activities and milestones. The project schedule provides a

03/10/2021
centralized, programmatic view of all workstreams for the One Washington Phase 1A implementation. Please
see Section 4.5 on Project Schedule Development for more details on how the project schedule will be
organized.
Please note that One Washington defines a workstream as the progressive completion of distinct tasks
and core activities that are completed by a specific work group and focused on a specific purpose. The
terms workstreams and subprojects may be used interchangeably throughout this plan.
4.3.2 Project Schedule Tools

The PMO is equipped with Microsoft Project 2016, which will be the tool for developing and managing
the project schedule in a Microsoft project plan (.mpp) file. This should be a major consideration in the
development of new schedules within the One Washington program.
For stakeholders who want to review the project schedule detail but lack Microsoft Project for viewing
capability, the project schedule can be exported into Excel or an Adobe PDF file. Please see MS Project Help for
detailed instructions.
Currently, the PMO has the Microsoft Project 2016 desktop application and NOT project server’s
project web application. Without PWA, the program is unable to incorporate certain enterprise
functionality, such as assignment owners. It is important to consider this current constraint in the
development of project schedules and communications.
Other tools used by the One Washington program to manage project schedules include:
 Visio
 PowerPoint (PPT), including Office Timeline Pro for PPT
 Excel
 SharePoint
 Microsoft Teams
 Planner
Planner is used within the One Washington program to create Kanban boards. The PMO Kanban board is used to
track the status of individual workstream activities and action items and is used to supplement the project
schedule. This tool helps organize and track workstream activities and action items that may feed into tasks in
the integrated project schedule.
The PMO Kanban board is used in PMO daily standup meetings to coordinate PMO team activities and ensure
that the team is working on the right priority items. The use of the PMO Kanban is expected to evolve and adjust

03/10/2021
as the overall 1A project progresses. Similarly, Microsoft Teams can also be used as a key collaboration and
sharing tool for project team members.
For more information on the program-wide tools that will be used on Washington, please see Section 12 Project
Tools Strategy Plan.
4.4 Project Schedule Roles and Responsibilities

Roles and responsibilities in the table presented below are focused on specific functions performed as part of the
schedule management plan.
Table 9. Project Schedule Roles and Responsibilities
Roles Responsibilities
Deloitte Project Manager  Oversee weekly updates to the integrated master schedule
 Monitor schedule for accuracy and impacts on critical path
 Check quality of schedule in terms of compliance with best practices for using
Microsoft Project as a scheduling tool
 Present task status weekly in the PMO Standup meeting
 Provide task status input for weekly workstream status report
 Provide status of schedule baseline; recommend when a baseline revision may
be necessary
OneWa PMO  Review project weekly and communicate findings to the Deloitte Project
Manager, OneWa Program Director, and Deloitte Program Director
OneWa Project  Manage program-level schedule status information; that is, budget, funding,
Coordinator and policy activity
 Collaborate with Project Manager and Scheduler on integrating program-level
status into the OneWa Phase 1A schedule
 Create weekly reports and/or ad-hoc reports, as needed
Deloitte Project Scheduler  Manage the Microsoft Project schedule
 Enter updates into the schedule
 Solicit updates weekly from Workstream Leads and the OneWa Project
Coordinator
 Ensure quality of the schedule in terms of compliance with best practices for
using Microsoft Project as a scheduling tool
Workstream Lead  Provide on-time input on task status within the workstream defined at Level 2
of the project work breakdown
OneWa Program Director  Provide guidance and oversight on the development and management of the
+ Deloitte Program project schedule
Director  Consider and make decisions on schedule-driven change requests
PMO manager  Provide guidance on the development and maintenance of the project schedule
Program leadership  Provide guidance on the development and maintenance of the project schedule
QA/OCIO oversight  Provide guidance on the development and maintenance of the project schedule

03/10/2021
4.4.1 Approval Authority for Project Schedule Changes

The project schedule baseline will only be changed at the request of the project manager for reasons outside the
control of the project team. Any schedule decisions impacting the program’s budget, critical path or completion
dates will follow the formal change control process that is described in Section 7 of this Playbook.
Changes to the project schedule baseline must be approved by the proper authority(ies) before being
incorporated into the plan and master project plan. The table below provides guidelines on the approval
authority required based upon the magnitude of the requested change.
Table 10. Approval Authority for Project Schedule Changes
Type of Change Impact Approval Authority

No impact to budget, major milestones, critical path or
Project Manager
project completion date
Addition or Impacts major milestones but does not impact critical Business
deletion of release budget or project completion date Transformation Board
project tasks
Executive Steering
Impacts release budget, critical path or project completion date
Committee
Project Manager
Changes to the Impacts major milestones but does not impact critical Business
completion date release budget or project completion date Transformation Board
of a task
Executive Steering
Committee
Project Manager
Change to task Impacts major milestones but does not impact critical Business
dependencies release budget or project completion date Transformation Board
Executive Steering
Committee
Provides a mechanism to re-align the schedule to Executive Steering
Re-baseline
negotiated, revised milestones or to address Committee
schedule
additions/removals of tasks.
4.5 Project Schedule Development

Owing to the size and complexity of this business transformation project, the PMO will manage the work as
related projects in a coordinated effort. This approach provides the program with flexibility to manage the

03/10/2021
program’s master schedule using a hybrid approach, using a combination of predictive (waterfall) and
adaptive (agile) approaches:
 Predictive approach for well-known, linear or sequential projects, such as for development of the
project management plans and program’s budget requests.
 Adaptive approaches for work with a larger amount of uncertainty, ranging from complicated to
complex.
 Iterative: allows for feedback on partially completed or unfinished work to improve or modify the work.
This approach is currently being used in developing the solution architecture and security
documentation by the One Washington technical team.
 Incremental: provides smaller finished deliverables within a given time increment. This approach has
been used for program planning, such as a rolling wave planning for the transitions to different phases as
outlined in the modernization roadmap.
 Agile: leverages both iterative and incremental characteristics.
For the One Washington program, the project schedule development process follows these development steps:
1. Define Scope and Timeline

 Inputs include: the SOW, Project Intake Form, standard WBS, and the One Washington program
timeline
2. Identify Tasks
 Define and sequence tasks; estimate durations and assign resources
3. Create Project Schedule
 Follow defined approach and WBS; define dependencies
4. Review and approve draft project schedule with key stakeholders; once approved, baseline project
schedule for monitor and control and reporting purposes during execution
5. Integrate project schedule with One Washington Program-level plan
4.5.1 Define Scope and Timeline

The first step of the schedule development process is to gain an understanding and/or refine the scope of the
project. Three tools that are important inputs to this step include:
1. Statement of Work
2. PMO Project Intake Form
3. Standard WBS template
4.5.1.1 Statement of Work

A statement of work (SOW) is typically associated with a vendor contract and outlines the specific activities,
deliverables and timelines for the vendor providing services. This type of documentation is critical in the
development of the vendor’s project schedule, or planning schedules with dependencies on vendor deliverables,
as the SOW will typically have these dates set in the contract.
Regarding a vendor SOW, the contract manager is responsible to ensure that the schedule is produced and
integrated into the program’s Master Project Plan. Please refer to the One Washington Vendor Management
Plan for more information.

03/10/2021
4.5.1.2 Project Intake Form

The Project Intake Form was created by the PMO as a mechanism for capturing incoming projects, subprojects,
or workstreams within the One Washington program. The purpose of this form is to clarify the work, the
deliverables, timeframes, and the roles and responsibilities of the team.
The project intake process includes:
1. Identify the need for a project, subproject, or workstream by any One Washington team member.
2. Fill out the project intake form in collaboration with the One Washington Project Management Office:
 This involves an iterative process to define the scope, deliverables, team members, and overall
timeline with key stakeholders.
 The PMO is responsible for ensuring that sufficient detail is included for the proposed body of work,
and that alignment with program goals and priorities is clear.
 The PMO Manager will work with the One Washington leadership team to validate the priority of the
proposed project/body of work.
3. Obtain signature(s) from the sponsor to authorize the use of resources on the identified body of work
outlined in the project intake form.
4. The identified project lead will work with the PMO to develop the project schedule – please see the
Work Breakdown Structure section below. The PMO will also assist the project lead with baselining the
completed, approved project schedule and integrating it into the One Washington Master Project Plan.
5. The project lead will provide status updates and reporting, as outlined in the Project Schedule
Maintenance section of this document.
A template of the Project Intake Form is available for use.
4.5.1.3 Standard WBS Template

Another tool that the PMO uses to help decompose the work outlined within the project intake form is a
work breakdown structure, or WBS. This method is used to identify the work that must be completed by the
project team in order to meet all project objectives and create the required deliverables.
For One Washington schedules:
 A milestone is, “a significant point or event in a project or program” (Practice Standard for Scheduling,
3rd edition).
 A deliverable is, “any unique and verifiable product, result, or capability to perform a service that is
produced to complete a process, phase, or project” (Practice Standard for Scheduling, 3rd edition).
Please note that the term deliverable may have additional meaning within the One Washington program.
Please refer to the Quality Management Plan section in this Playbook for the program’s defined
processes for deliverable management, which includes contract deliverables, non-payment deliverables,
and work products.
Creating a hierarchical decomposition of a project deliverable into subcomponents through progressive
elaboration makes identifying all the work packages needed for creating that deliverable much easier. According
the Practice Standard for Scheduling, 3rd edition:

03/10/2021
 Progressive Elaboration is: “…the iterative process of increasing the level of detail in a project
management plan as greater amounts of information and more accurate estimates become available.”
 A Work Package is: “…the work defined at the lowest level of the work breakdown structure for which
cost and duration are estimated and managed.”
The One Washington project schedule will be deliverable-based. The standard WBS for One Washington projects
is defined in the table below:
Table 11. One Washington Project Standard WBS
Level Definition One Washington Sample(s) WBS Format

0 Project Summary Plan 1A <Name>
(Release)
1 Stage Plan, Architect, Configure and X
Prototype, Test, Deployment,
Sustainment
2 Workstream Project Management, Functional, X.XX
Architecture and Security, etc.
3 Activity Collection of related tasks to get X.XX.11111
something done
4 Task/ Step/Milestone Develop Project Charter X.XX.11111.1111
In addition, the One Washington PMO has created a WBS dictionary template for use with the project intake
form. Please see the figure below for a sample of this standard WBS template and contact the PMO for further
assistance with development of a project WBS.
Work Breakdown Structure (WBS) Dictionary
WBS Task Resources Update Predecessor Task Start Finish

Level Task Notes Names Source (Task ID) Duration Date Date
0 Project Summary Summary task for N/A N/A No Project Total Project Start Phase 1A End Date
Phase 1B Duration Date
1 Project Stage Plan, Architect, N/A -N/A No Calculated based Calculated Calculated based on
Configure and on sum of task based on first task start plus the
Prototype, Test, durations predecessors cumulative duration
Deployment, of tasks of subsequent tasks
Sustainment
1.1 Workstream Project -N/A No Calculated based Calculated Calculated based on
Management, on sum of task based on first task start plus the
Functional, durations predecessors cumulative duration
Architecture and of tasks of subsequent tasks
Security, etc.
1.1.1 Activity Collection of tasks - N/A No Calculated based Calculated Calculated based on
that results in an on sum of task based on first task start plus the
output, e.g., work durations predecessors cumulative duration
product, of tasks of subsequent tasks
deliverable,
milestone event

03/10/2021
Work Breakdown Structure (WBS) Dictionary
WBS Task Resources Update Predecessor Task Start Finish

Level Task Notes Names Source (Task ID) Duration Date Date
1.1.1.1 Task Lowest level of One or more One or more Yes Entered Calculated Calculated based on
decomposition: a Last Name of Last Name of manually based on task start plus the
discrete Step/Task, the lead on the associated predecessors duration of the task
Deliverable, task; no names Workstream of task
needed for Lead
Milestone, work products,
Dependency deliverables,
milestones
Figure 10. One Washington Standard WBS Dictionary Template
4.5.2 Identify Tasks

After the project manager has a good understanding of the project’s scope, they need to identify tasks needed to
create the project deliverables. These steps align with the following PMBOK® Guide processes:
1. Define activities and tasks

2. Sequence activities and tasks
3. Estimate activity and task durations
4.5.2.1 Level of Detail

PMI has several best practices that are referenced within the PMBOK® Guide and the Practice Standard for
scheduling. PMI emphasizes tailoring practices to fit the needs of the project to complete the work successfully.
The One Washington program will decompose all project work to a level that enables
adequate management, monitoring, and progress reporting.
Specific deliverables or sections of the plan may have differing levels of detail, in accordance with PMI best
practices to ensure enough useful details to complete the work successfully.
Activities and Tasks
The schedule includes all the activities and tasks needed to produce the deliverables. An activity is a collection of
tasks, and a task is a distinct, scheduled portion of work performed during the course of a project. When creating
the description of tasks, each activity should start with a verb and contain a unique, specific objective so it is
clear and not ambiguous or open to individual interpretation.
For additional clarity and consistency in the project schedule mpp file, One Washington also specifically identifies
deliverables and milestones within a project schedule using standard naming conventions and call-outs to
further enhance specificity. For example:
 M: name of milestone
 Deliverable: name of deliverable

03/10/2021
Decomposition
Per the 1A SOW: “No individual task will be longer than four weeks in duration, with a preference for less than
two weeks per Contractor’s QA vendor.” So, where possible, activities should be decomposed into tasks that can
completed in two weeks or less (i.e., 10 working days); or four weeks (i.e., 20 working days) at a maximum. One
exception to this Decomposition guideline is an activity or task within the project schedule that represents a
continuous activity, to be performed throughout a project phase or the entire project lifecycle. We may identify
other exceptions as the project schedule continues to be progressively elaborated.
According the Best Practice Standard for Scheduling (3rd Edition), consideration to the level of
granularity should be considered and the level of detail can be different for every project.
4.5.2.2 Task Dependencies

In order to create a dynamic schedule where delinquency impacts can be determined, tasks must be connected
through Predecessor-Successor dependency relationships. There are four types of dependencies (logical
relationships) that are used to create links between project schedule tasks:
 Finish-to-Start (FS): The initiation of the successor activity depends upon the completion of the
predecessor activity.
 Finish-to-Finish (FF): The completion of the successor activity depends upon the completion of the
 Start-to-Finish (SF): The completion of the successor activity depends upon the initiation of the
 Start-to-Start (SS): The initiation of the successor activity depends upon the initiation of the predecessor
activity.
Tasks are linked together and sequenced to identify the relationships between deliverables, sub-deliverables,
activities, tasks and subtasks.
Dependencies
The following rules should be applied when creating task dependencies:
1. With minimal exceptions, all tasks should have at least one successor and predecessor, so there are no
unlinked tasks to avoid open-ended or “Fixed Date”-constrained activities.
Open-ended or “Fixed Date” activities are any activities that lack either predecessor or successor
and obscure the logical relationships between project activities, creating the false appearance of
float in a project schedule.

03/10/2021
Having too many open-ended activities in the schedule makes it difficult to assess impacts of changes
or determine the critical path. Therefore, One Washington will seek to minimize the use of open-
ended activities and tasks.
2. Summary activities or tasks should not have any specific successor or predecessor identified. Summary
activities are a group of related schedule tasks aggregated and displayed as a single activity. For
purposes of modeling the critical path, all dependencies should be linked to a detail task or deliverable
and NOT to a summary activity or task.
3. Start and finish dates should not be entered when creating new tasks. Instead, predecessor activities
determine the start date and the estimated duration determine the finish date.
4. Date constraints should be applied sparingly (i.e., only when required or when actual constraint exists) in
order to maintain a dynamic, realistic schedule. For example, only hard deadlines that represent a
constraint to the One Washington program should be entered into the project schedule as Fixed Date
tasks; self-imposed, internal team deadline dates should not be defined for a task.
Use caution when adding date constraints to project schedules, as they restrict the dependency
relationships and affect the schedules flexibility by limiting its ability to react to changes. Date
constraints should be avoided when possible and only be used after careful consideration of how they
impact the project schedule over its entire lifecycle. Within One Washington, only deliverables or
milestones with hard deadlines should be inserted as date constraints and not include any internal self-
imposed deadlines.
Special instructions for WaTech Dependencies
Based on an 8/24/2020 meeting between One Washington, WaTech and OFM IT, a carrot symbol (<< or >>) will
be used in the task naming convention to denote dependencies between One Washington, WaTech and OFM IT
project plans, where relevant:
 << Signifies an outgoing task dependency for a One Washington task

 >> Signifies an incoming task dependency for a One Washington task
This methodology will allow One Washington, WaTech, and OFM IT to have separate and distinct project plans
for projects managed by the separate agencies but also allow for critical co-dependences to be acknowledged
and managed.
4.5.2.3 Estimate Durations

One Washington staff will work with the PMO to estimate task durations, using a combination of analogous,
historical and expert judgement estimation techniques. Analogous estimation, where the estimate is based on
information from similar work in the past, offers less risk than other estimation approaches. When data from the
past is unavailable, estimates will be based on the expert judgement of subject matter experts.

03/10/2021
Most tasks should have a required duration to complete the work, but there will be some tasks that are based on
effort. A level of effort task is defined as: “a task that does not produce definitive products and is measured by
the passage of time.” When level of effort tasks are added to the project schedule, there must be clear
communication and understanding about the true resource effort needed and how much time will be allocated
to the work.
4.5.2.4 Identify Resources

Identifying the resources necessary to complete required tasks for the project is a critical step in the
development process. The people that “actually do the work” are subject matter experts that assist project
managers with creating or validating the deliverables, identifying tasks and developing accurate time estimates.
The organizational chart is a useful reference document that provides a hierarchical-tree diagram of the
organization and resources. The One Washington business operations team manages the organizational chart for
the program. Additional information is available in the Resource Management Plan section of this Playbook.
For external projects related to the One Washington program, it may be necessary for the
project manager to create an organizational chart that identifies resources specific to their
project.
Another tool that can be useful is a resource assignment matrix (RAM). The most common RAM is the RACI
matrix for describing resource assignments and responsibilities in relation to tasks. The previous Project
Organization section of this Playbook presents the Program and Technical RACI for the One Washington
program.
For the One Washington Phase 1A implementation project, project schedule tasks will be assigned at the “Team
Lead” level, and that person will be responsible/accountable for getting the work done, as well as providing
weekly updates on his/her respective assigned tasks. The best practice is to assign one accountable person or
Team Lead to each task.
For the One Washington program schedule, each summary activity will at a minimum, specify the
main contact that is responsible for ensuring the work is tracked through completion.
4.5.3 Create Project Schedule

Based on the information gathered in the “Identify Project Tasks” step, the project manager or designated
project lead will work with the PMO to build out the project schedule, to include the components listed below
that are based on Microsoft’s available fields reference for MS Project.

03/10/2021
4.5.3.1 Project Schedule Components

Within MS Project, the following fields are mandatory:
Table 12. Project Schedule Fields - Mandatory
Field Description
Task Name The Name field contains the name of a task or a resource.
Predecessors The Predecessors field lists the task ID numbers for the predecessor tasks on which
the task depends before it can be started or finished.
Start The Start field shows the date when an assigned resource is scheduled to begin
working on a task.
Finish The Finish field shows the date when a task is scheduled to be complete. It is automatically
calculated, based on the task duration and project working time defined (including holidays
and/or black-out dates).
Duration The Duration field shows the total span of active working time for a task.
Percent (%) The % Complete field contains the current status of a task, expressed as the
Complete percentage of the task's duration that has been completed.
Team The Team name of the resource(s) responsible for a task.
Resource The Resource Name field contains the name of an individual(s) responsible for a task.
Names
The following fields are optional but encouraged when information is available:
Table 13. Project Schedule Fields - Optional
Field Description
Notes The Notes field contains comments you can enter about a task, resource, or assignment.
Work The Work field shows the total effort scheduled on a task for the assigned resource(s), in
hours.
Actual Start The Actual Start field shows the date and time that a task or an assignment actually began,
based on progress information that you entered.
Actual Finish The Actual Finish field shows the date and time when a task or assignment was completed.
Deadline The Deadline field shows the date you enter as a deadline for the task. A deadline is a
target date that indicates when you want a task to be completed.
Priority The Priority field indicates the level of importance given to a task, which in turn indicates how
readily a task or assignment can be delayed or split during resource leveling.
4.5.3.2 Duration Rules

The PMO will work with the project manager to develop a schedule that meets the program needs for the
required level of granularity for tracking task completion and reporting. As previously stated, the preferred level

03/10/2021
of granularity for tasks is that which is needed for adequate monitoring and reporting and to assure successful
completion.
The 8/80 rule, which decomposes tasks to no less than 8 hours or no more than 80 hours, will
be encouraged, unless project managers can explain when and why it is not applicable for a
task.
Within MS Project, durations are calculated based on the project calendar and working time/day definitions. The
following conversion table can be used to determine durations in the project schedule:
 Eight hours or less = One day

 One working week = Five (5) days
 One working month = Twenty (20) days
It is important to define any One Washington holidays, plus any other blackout days throughout the forecasted
timeline for the project upfront, so they are not treated as working days while the schedule is being developed.
In summary, the project schedule should contain:
 Activities, Deliverables and Tasks

 Milestones – zero effort/zero duration tasks that identify:
o Project Start and Project Finish
o Phase and/or Sprint completions; “Phase-Gate” milestones
o Deliverable or other event-based payments
o Other key events (e.g., Go-Lives, Kick-Offs)
 Duration (the span in days between the Start and Finish date of each task)
 Dependencies (a set of predecessors and successors that define the critical path of the project)
 Responsible resources (the accountable-responsible resource for each task or task deliverable)
4.5.4 Approve and Baseline Project Schedule

A baseline is an approved version of a work product that can only be changed through formal change control
procedures. It is used as the basis for comparing actual project progress against the baseline schedule.
Therefore, it will be important to baseline the schedule before project work commences.
The documented change control process described in Section 7 of this Project Management Playbook
will be used when the schedule needs to be re-baselined.

03/10/2021
For reference, here are some key features of baselines within MS Project 2016:
 A baseline is a group of nearly 20 primary reference points (in five categories: start dates, finish dates,
durations, work, and cost estimates) that are set to record the original project plan.
 As the project progresses, One Washington can set up to a total of 11 additional baselines for each
project in order to assist with measuring changes to the project plan.
o The latest baseline will always be used by MS Project to measure and report progress against the
plan, based on the Project Status Date specified.
For more information about baselining in MS Project, please refer to this Microsoft article: Set and save a
baseline.
For the One Washington Phase 1A project, the project schedule should be baselined once fully complete and
approved by the One Washington PMO during planning; then the baseline will be used to measure “progress
against the plan” during execution and implementation of the project.
New tasks added to the baselined project schedule will need to be individually baselined when approved by the
One Washington PMO (plus their respective roll-up tasks to account for them properly), but the entire project
schedule should only be re-baselined after an approved CR to change the critical path components of a One
Washington release, including scope, schedule and cost/budget. Please see Section 7 Scope Management and
Change Control in this Playbook for more information.
4.6 Project Schedule Maintenance

The project schedule will be maintained by the One Washington PMO, working closely with project managers
and under the direction of the PMO manager.
Schedule updates will be published weekly, or as often as necessary and will be posted to the program’s
SharePoint site. The schedule information will be presented to executives and staff in the weekly status report.
For additional understanding of how the One Washington master schedule is updated and weekly
reports are developed, please refer to the weekly schedule updates and reports guide in
SharePoint.
4.6.1 Project Schedule Updates

The project schedule will be updated as outlined below to ensure that an updated version is made available for
status reporting and decision-making purposes.
The project schedule is a living document where:
 Appropriate tasks and resources are represented at a level of detail needed to support status reporting
requirements, the variable demands of management review and decision-making, and the operational
demands of managing time and scope.

03/10/2021
 Changes to the project schedule are accommodated by the approved addition, deletion or changing of
tasks, as defined in the Project Governance Plan and Scope Management and Change Control Plan
sections of this Project Management Playbook.
 Changes to task status (i.e., percentage complete), durations and resources are addressed by the update
process.
The schedule task/activity update process for One Washington projects will strictly follow the update parameters
defined in the table below:
Table 14. One Washington projects – update parameters
% Complete Description
0% Task has not started
20% Task is started and there is documented progress
40% Task is well underway with documented progress
60% Task is more than half complete and remaining work is well understood
80% Task is close to complete and remaining work is well understood
100% Task is complete
The six (6) update options in the table above are the only updates that will be used in updating the One
Washington Phase 1A project schedule.
4.6.1.1 Weekly Project Schedule Update Process

The Deloitte Project Manager and the Scheduler will coordinate with Workstream Leads to gather weekly
schedule updates, following the cadence presented in the table below:
Table 15. Weekly Project Schedule Update Process
Manage Work Plan Description Responsible Timing

Step
Publish Assignments The updated project schedule for Deloitte Project Manager Friday
the next week is available to all
project team members.
Track Progress Deloitte Project Manager and Accountable/responsible Thursday by 1 pm
Scheduler solicit task updates from Team Leads PT
Workstream Leads, who provide
actual start dates, percent
completes, and actual finish dates
of assigned tasks.
Updates will forecast status
through end of the work week.
Analyze Progress and The task progress tracking is Deloitte Project Manager Friday
Performance reviewed to determine the impact PMO Manager
upon the project schedule;

03/10/2021
findings to be reported at Monday
PMO Stand-up Meeting.
Re-plan Project leadership adjusts the Deloitte Project Manager As needed
Work Plan (if necessary) in light of PMO Manager
changing circumstances, through Team Leads
the use of a change request.
To accomplish the above activities, the following will be performed:
 Publish Assignments – let team members know their tasks for the week
 Track Progress – each accountable/responsible Team Lead will provide the PMO their respective task
updates by 12 noon PT every Friday, following the progress options defined in the previous table:
o Task update options are: 0%, 20%, 40%, 60%, 80% or 100% Complete
 Analyze Performance – the project manager and PMO Manager will leverage MS Project capabilities to
review the project schedule after the track progress activity is complete. This analysis will consider:
o Critical Path
o Late/slipping Tasks
o Deliverable/Activity/Milestone Completion Rate
o Actuals versus scheduled work
 Re-plan – the project manager and PMO Manager will review the latest project schedule in MS Project
after incorporating progress tracking updates, as well as any other date changes to in-inflight or
upcoming tasks.
o This review will evaluate currently planned vs. baseline dates for milestones to determine if
actual progress is impacting critical dates
o If issues are identified, the project manager and PMO Manager will revise the project schedule
(e.g., add lag, adjust assignments, augment resources, etc.) to bring the schedule back on track
o Significant delinquencies and/or correction actions impacting the 1A critical path will need to be
escalated to the ESC
 The project manager and PMO Manager also need to adjust the project schedule during re-planning to
implement any approved change requests for the project received that week.
In preparation for the weekly status report, any concerns or issues about late/slipping tasks and impacts on the
critical path will be discussed between the Deloitte Project Manager and PMO Manager, and corresponding
corrective actions will be identified. The updated project schedule from last week will be archived; and the
revised project schedule for the upcoming week will be published.
Escalation of schedule variations will be in accordance with Governance Plan guidance.
When reporting schedule progress, the project manager responsible for the project schedule will set the status
date within MS Project. Please see the Microsoft article: Set the status date for project reporting.

03/10/2021
4.6.1.2 Version Control and Back-ups

The PMO will create a backup of project schedules:
 Any time a project schedule is baselined or re-baselined

 On a recurring or as-needed basis determined by the PMO
The PMO maintains the official version of all project schedules within the One Washington
program SharePoint repository, as part of its configuration control to ensure proper records
management.
The PMO will determine the appropriate and logical naming convention for the project schedules, including
version control and backups.
Records Retention
The One Washington program will follow state laws and OFM record management policy 1.09 for all records
retention. For more information about records retention and the OFM records coordinator, please see this OFM
website for retention RCW/WACs, schedules, policies, forms, and coordinators.
Chapter 42.56 RCW requires that state and local agencies to disclose any public record upon request, unless the
record falls within certain specified exemptions.
4.7 Project Schedule Reporting and Communications

The project schedule, including any significant timeline changes or issues, will be communicated to the project
team, program leadership, governance committees and other stakeholder groups as part of regular status
meetings and weekly reports.
Clear, timely and concise communications help the One Washington program build credibility. The project
schedules and Master Project Plan serve as strategic documents used to guide the program and stay on target.
Project schedules with the appropriate level of detail will aid in effective communications and minimize delays by
identifying and addressing delinquencies in project schedule progress on a weekly basis.
The One Washington program will continue to maintain transparency, and the Master Project Plan is one of the
key ways the program will communicate with stakeholders.
4.7.1 Reporting
The PMO is responsible for creating multiple reports based on the One Washington Master Project Plan and
project schedule. Some examples of weekly reports include:
 Timeline Updates
 Late Tasks Report
 Upcoming Tasks Report

03/10/2021
 Milestone Report
Please see the Project Status, Internal Communications, and Meeting Management section of this Playbook for
more details on the templates and processes that will be used to create regular status reports for the One
Washington program.
4.7.1.1 Timelines
The One Washington program timelines are used to show progress in different workstreams based on updates
derived from their related project schedules.
4.7.2 Weekly Reports

The PMO creates the schedule report weekly and stores the reports in the designated SharePoint location. The
majority of the weekly PMO reports are based on pre-defined MS Project reports. For more information about
pre-defined reports within MS Project, please refer to these Microsoft articles:
 Pick the right report in Project

 Create a project report in Project desktop
The weekly reports will include:
 Late Tasks: The late tasks report is based on the pre-defined MS Project formula for filtering on late
tasks. The report lists all tasks that started or finished later than their scheduled start and finish dates
and are not progressing as planned.
 Upcoming Tasks: The upcoming tasks report is based on the predefined MS Project report. This report
shows the work that has been done in the current week, the status of any remaining tasks that were
due, and what tasks are starting in the next week.
 Milestones: The milestone report looks at past due milestones and milestones that are coming within
the next month.
The One Washington program does not currently use, and does not intend to use, earned
value management.
Please see the Project Status, Internal Communications and Meeting Management section of this Playbook for
more details on how One Washington status reports will be produced and distributed.
4.7.2.1 Quality Performance Metrics

One Washington program quality performance metrics will be used to measure performance and progress
towards goals. The schedule performance metrics are used to provide accountability and the program’s ability to
deliver on time, as planned. This helps program leadership and governance understand how the program is
progressing over time.
This table below describes what metrics will be reported on a monthly basis for inclusion into the monthly PMO
status report:

03/10/2021
Table 16. Quality Performance Metrics
Metric Calculation Method Target

Percent of critical path tasks and milestones # of milestones completed late / #
<10%
completed on time milestones (%)
Number of schedule changes that cause a change
# of changes / # of milestones <10%
to milestone completion date or Go-Live date

03/10/2021
5. Cost Management Plan
5.1 Introduction
This One Washington project cost management plan includes the processes involved in planning, estimating,
budgeting, financing, funding, managing and controlling costs so the project is able finish within the approved
budget. A glossary of key cost management terms is provided at the end of this Playbook section for reference.
The overall success of the One Washington program depends on effective cost management, as cost will be a
primary determining factor for the success or failure of the overall ERP implementation.
5.2 Purpose
The purpose of the cost management plan is to:
 Identify key stakeholders and outline roles and responsibilities

 Outline One Washington’s budget process, including:
o Decision package development
o Budget development before and after funding is secured
o Financial status review
o Budget changes (analyzing, approving, executing)
 Outline the legislatively-mandated OCIO Gated Funding process, as it relates to One Washington
 Define various financial reporting requirements
 Define the invoice management process
5.3 One Washington Budget Background

One Washington’s primary funding source is legislative appropriation, utilizing the central service model to
allocate costs across agencies, as One Washington will benefit all agencies, higher education, etc. To date, this
has been the main funding vehicle.
The table below shows the current schedule of past, present, and future biennial funding.
Table 17. One Washington Budget Background
Biennium Amount Description

2013–15 $2.4 million Prepared to modernize the State’s overarching financial systems and produced a
business case (research).
2015–17 $2.0 million Performed readiness activities by collecting state agency and legislative financial
system needs, and streamlined the account code structure to migrate to the new
system.
2017–19 $12.6 million Continued readiness activities, prepared program blueprint, and hired quality
assurance contractor.
2019–21 $38.6 million 2019–21 biennial budget: $38.6 million ($18.4 million + $20.1 million
supplemental)
Select ERP software and system integrator (subscribe to the services) and related
preparatory steps to begin implementation of the financial system (AFRS)
replacement.

03/10/2021
Biennium Amount Description

2021–23 TBD
2023–25 TBD
5.4 Roles and Responsibilities

The table below describes the One Washington budget and cost management stakeholders, their roles, and their
responsibilities.
Table 18. One Washington Budget and Cost Management Stakeholders Roles and Responsibilities
One Washington Budget  Develop, oversee and report on budget
Manager  Provide budgeted cost and actual spend figures upon request
 Review and code invoices after they have been
reviewed/approved by the appropriate contract manager
 Send invoices and related documentation to the OFM Finance
team for payment processing
 Complete necessary allotments/journal vouchers and other
finance-related activities for the program
 Provide oversight for any One Washington funding pools
 Serve as OCIO technology budget point-of-contact
 Develop and maintain all One Washington technology budgets
 Provide input for all One Washington investment plans
One Washington Budget  Help manage funding/reporting for the Agency OCM pool and One
Analysts Washington technology pool
(If funded)  Conduct bill analysis-during legislative sessions, review bills that
may impact One Washington and identify/quantify any impacts
One Washington Business  Support the Budget Manager in developing the budget, and
Operations Manager oversee the change control and deliverable review processes
 Work with appropriate resource managers and HR representatives
for program staffing
One Washington Program  Verifies that deliverables are complete before an invoice is
Director approved
One Washington  Approves changes, from the currently approved technology
Executive Director budget, to the finally submitted budget
One Washington  Approves all budget changes of more than 10% of project total,
Executive Sponsor phase total, biennium total, FY total, gate total
One Washington Project  Oversees the development and quality of for the deliverables
Management Office within the technology budget
OFM Finance Team  Executes, or assists with finance activities: e.g., vendor payment
processing, official contract payment logs and financial records
retention, allotments, journal vouchers
OFM Budget Office  Provide assistance with budget request development

03/10/2021
 Helps with OCIO-Gated Funding process and legislative staff
engagements
Office of the Chief  Oversees the Gated Funding process that One Washington must
Information Officer follow
One Washington Contract  Review contractor invoices by the appropriate state staff,
Managers managing the contract to ensure that: the amounts are correct
(per the contract and budget); the appropriate level of detail is
represented; and the work was completed to the State’s
satisfaction prior to being sent to the budget manager and
business operations manager
One Washington  Approves all budget changes of more than 10% of project total,
Executive Steering phase total, biennium total, FY total, gate total
Committee
One Washington Business  Approves all budget changes of more than 5% of project total,
Transformation Board phase total, biennium total, FY total, gate total
5.5 Cost Management Approach

A cost management approach outlines the methods to use and the level of rigor to apply to establish a cost
baseline, and assess actual costs against the budget. The One Washington program uses a proven cost
management approach that has been employed in multiple large projects and centers on:
 Qualified personnel: One Washington will leverage experienced financial staff, who are well versed in
both state and industry standard best practices. The program will include a dedicated budget manager
for managing the project budget and expenditures.
 Deliverables/milestone-based contracts: Vendor contracts are either (1) fixed price, or (2) hourly rate,
with a “not to exceed” amount with deliverables/milestones. Vendor payments only occur when a
deliverable/milestone is accepted by the State. Payments are commensurate with deliverable/milestone
progress, regardless of the level of effort expended by the vendor.
 Regular reporting of budget against actuals: One of the prime responsibilities of the dedicated budget
manager is to produce monthly budget status reports, including financial status, showing actual and
projected expenditures against budget amounts through the reporting period (typically by fiscal year).
The monthly reports cover all project costs, including various contracts and State costs. The report will
also provide a projection of anticipated expenditures including contract impacts.
 Formal invoice process: All vendor invoices are reviewed by appropriate State staff managing the
contract to ensure amounts are correct (per the contract), the appropriate level of detail is represented,
and the work was completed to the State’s satisfaction prior to being sent to the budget manager. See
the Vendor Management Plan for more information regarding the vendor invoicing process steps.
5.5.1 Stages of Cost Management

The high-level stages of cost management are:
1. Resource planning: This process begins with an approved One Washington scope and timeline used to
understand the components and budgeted resources needed to ensure One Washington is successful in

03/10/2021
implementing the statewide ERP system. Resource acquisition can include team members, facilities,
equipment, materials, supplies, and other items necessary to complete project work.
2. Cost estimation: Estimates are quantitative assessments of the likely amounts of project costs,
approximation of the monetary resources needed to complete the project work. One Washington will
work with the appropriate internal and contractor subject matter experts to gather estimates. When
developing estimates for project costs, it is important to document the basis of the estimate. This
supporting material outlines the method used in establishing the estimates, including assumptions,
constraints, level of detail, and ranges. Estimates, are refined through an iterative process that:.
 Is designed to change as the project changes and more information becomes available
 Uses several estimation techniques, the selection of which is determined by conceptual goals,
historical knowledge, expert judgement, determinative techniques or a component-by-
component basis
3. Budgeting: The cost estimates are used to map the blueprints for the budget. Budgets are formed after
the estimation phase, and are typically released in a series of phases depending on the project’s
progress. This will help the project reach its milestones within each budgetary phase, rather than trying
to match an overall project budget. While the initial budget will be based on cost estimates and
identified resource needs, each fiscal year the budget, scope, and/or schedule will be adjusted to match
the program’s current funding for that time period.
4. Cost Baseline. The term “baseline” within project management means: “the approved version of a work
product that can be changed only through formal change control procedures.” The cost baseline
represents the authorized and approved version of the time-phased project budget, which is used as
basis for comparison to actual results for measuring cost performance.
5. Cost control: This stage focuses on measuring the project’s dollar value performance against the total
cost and timeline. This provides a benchmark throughout the project process, by:
 First, establishing requirements well in advance, during the project planning phase
 Then, applying the requirements to challenge reasons for changes in cost. This will help to
course-correct should a cost increase out of budgetary range
6. Cost Change Control: This process is followed to make changes to the cost baseline and approve those
proposed changes. For One Washington, all changes that impact the currently approved technology
budget will follow the process outlined in this document under Section 7. Scope Management and
Change Control Plan.
For the One Washington program, the cost baseline is the currently approved Technology Budget(s), which are
available externally on the One Washington OCIO IT Project Dashboard.
Any potential changes (scope, schedule, or budget) to an approved technology budget will be discussed with the
budget manager prior to those changes being implemented in order to: quantify impact(s) to the One
Washington budget, identify any needed changes to the technology budget(s) and review any changes with the
executive director and/or appropriate governing body.
Examples-
Staffing-any changes to program staffing including: new positions, the timing of hiring, annual salary, etc.

03/10/2021
Contracts-any changes to contracts including: new contracts, extensions, increases to contract totals, scope of
work, change orders, etc.
5.6 Plan Funding Requests

This section describes the processes for funding requests: decision package development, biennial funding,
supplemental funding, decision package support documentation, reviews and approvals, IT addendum, decision
package submission, and budget request communications
5.6.1 Decision Package Development

Budget requests are submitted through a decision package (DP), which is a budgeting tool to make a case for a
proposed agency budget change, including IT projects. The project/program must describe and support each
requested incremental change to the current budget with a DP.
The detailed instructions for submitting a decision package are presented in the OFM budget instructions. During
the development of the OFM budget instructions, the One Washington program will collaborate closely with
OFM Budget for the inclusion of any One Washington-specific instructions.
Once the OFM budget instructions are posted, the One Washington budget manager will coordinate with the
leadership team to identify all components needed for the upcoming funding request and cost estimates,
applying an iterative approach to obtain the information needed for the funding request and all related
projected costs. For example, each component of the funding request will include:
 A high-quality narrative description, plus any tables, charts, timelines, or other graphics that can assist
with the justification are strongly encouraged
 Detailed assumptions and calculations that support the proposed expenditures
5.6.2 Biennial Funding

Washington State enacts budgets on a two-year cycle, beginning July 1 of each odd numbered year. For example,
the budget approved for the 2019–21 biennium remains in effect from July 1, 2019, through June 30, 2021. By
law, the Governor must propose a biennial budget in December, the month before the Legislature convenes in
regular session.
5.6.3 Supplemental Funding

The biennial budget enacted by the Legislature can be modified in a legislative session through changes to the
original appropriations. These modifications are referred to as supplemental budgets. 2
A supplemental budget is an opportunity for One Washington to request changes to the original biennial budget
appropriations. Generally, a supplemental budget represents mid-course corrections to the two-year spending
plans.
2
See A Guide to the Washington State Budget Process

03/10/2021
5.6.4 DP Support Documentation

Along with the decision package narrative, the following supporting documentation may be included to provide
supplemental information as a basis to support the funding request:
 Analysis Excel workbook to support detail calculations and summary information of each item of the
program’s request
 OFM staffing model for calculating full-time equivalent (FTE) costs by object
 Base funding explanation that identifies the carry-forward funding available for the upcoming biennium,
and the plan for how these funds will be allocated to existing State staff and vendor contracts.
5.6.5 Reviews and Approvals

The One Washington budget manager will facilitate DP reviews from key stakeholder groups, which may include
the:
 Program leadership team

 Budget advisory committee
 Independent quality assurance
 Business owners
 OFM Finance
 OFM Budget
 OCIO
The executive steering committee, business transformation board, and legislative staff will be informed of the
pending funding request, to include an overview and key highlights.
The final approving authority of any One Washington funding request will be the One Washington Program’s
executive sponsor, via the program executive director.
5.6.6 IT Addendum
As outlined within the OFM budget instructions, all DPs with IT costs must include a completed IT addendum.
Therefore, One Washington will be required to submit an IT addendum and a fiscal estimate workbook with any
funding request. The OCIO reviews agency DPs each budget cycle to assess how agency IT requests are aligned
with the Washington State Enterprise Technology Strategy and posts a prioritization ranking to their website
5.6.7 DP Submission
After all reviews and approvals are complete, the decision package and supporting documents are officially
submitted to OFM finance for uploading into the agency budget system.
The One Washington budget manager will:
 Work with the assigned OFM budget assistant to prepare for the legislative session
 Be responsible for all fiscal details and overall quality of the proposal, including the detailed assumptions
and calculations
 Serve as the point of contact for the DP

03/10/2021
 Review the DP and supporting documentation with legislative fiscal staff, providing the opportunity to
answer legislative members’ questions
The One Washington enterprise business consultant will be responsible for coordinating and integrating the
narrative portion of the DP, including the strategic and performance outcomes
One Washington funding requests and supporting documentation can be viewed externally through a public
repository after the official submission.
5.6.8 Budget Request Communications

A one-page document providing a summary-level breakdown of each One Washington funding request will be
created for sharing with various stakeholder groups, and a PowerPoint document will be created to share
summary-level information and highlights of funding requests.
5.7 Funding and Budget Development

This section outlines the process of adjusting the program’s estimated budget, for the appropriate timeframe, to
match approved funding.
After a biennial or supplemental budget has been approved, the budget manager works with OFM budget to
identify the details of the program’s approved funding, including timing (biennial or fiscal year), provisos, etc.
The budget manager compiles potential budget options to review and discuss with One Washington’s leadership.
Depending on the level of funding received, leadership may need to make decisions related to scope, schedule,
staffing and vendor contracts. Depending on the size of the impact appropriated funding has on the scope
and/or schedule, leadership may make decisions internally or use the program’s governance structure.
After One Washington leadership and/or the appropriate governing body makes any necessary budget-impacting
decisions, the budget manager will revise the budget appropriately. At the next OCIO gate, the budget manager
will include these budget updates in technology budget revisions. This budget along with the related, approved
technology budget are used as the program’s cost baseline.
5.8 Invoice Processing

One Washington invoice processing will follow the guidance outlined in the vendor management plan. Below is a
summary of the steps necessary for invoice processing.
1. Invoices will be submitted to the contract manager.

2. The contract manager will review the invoice for accuracy and confirm that any related deliverables have
been completed to the program’s satisfaction.
3. The contract manager will approve the invoice and email it to the budget manager. The body of the
email should contain the statement of invoice approval and note that it is ready to be processed.
For the invoice to be processed, the budget manager will send OFM Finance/Accounts Payable the invoice,
contract manager’s approval, and the appropriate chart of accounts coding.

03/10/2021
5.9 Cost Control and Reporting Processes

Monthly reports on the budget status will be the responsibility of the budget manager. The reports will be
shared with One Washington executive director and other members of the One Washington leadership team as
part of the regular, on-going status report. These reports, particularly the One Washington financial status
report, will be used to allow the leadership team and/or appropriate governing body the opportunity to discuss
areas of concern and potential changes to the budget, scope and/or schedule.
5.9.1 Key Performance Metrics

Key performance metrics focus on budget vs. actual and forecast estimate at completion vs. budget at
completion:
The table below summarizes the One Washington status reports produced on a monthly and quarterly basis that
include budget and cost management status information:
Table 19. Key Performance Metrics
Report Name Metrics Frequency

One Washington PMO The current Fiscal Year total project budget versus spend Monthly
Status Report (cumulative totals by month)
One Washington Percent variance between forecasted expenditures and actual Monthly
Performance Quality expenditures
Metrics
One Washington Fiscal Enterprise Reporting- by vendor and allotment expenditure Monthly
Reports (Legislative revenue status flexible. Web intelligence report-expenditure
Staff) details, by fiscal month, by object and vendor.
One Washington Report includes: expenditures for the quarter, projected Quarterly
Quarterly Report to expenditures for the next quarter, contractor FTE equivalent,
Legislative Fiscal deliverables-completed and projected.
Committees
One Washington Report includes: current expenditures FYTD, projected Monthly
Financial Status Report expenditures for the biennium, assumptions, areas of concern,
etc.
5.9.2 Analytics and Ad-hoc Reporting

Analytical techniques are used to evaluate, analyze, or forecast potential outcomes based on changing project
variables and their relationships to other variables. The One Washington budget manager is frequently asked to
create ad-hoc reports for key stakeholders. These reports will compile data from the technology budgets,
decision packages, and other approved artifacts.
5.9.3 Cost Variance Plan

Cost variance is when the actual cost amounts differ from the approved budgeted amounts. Each month, after
fiscal month close, the budget manager generates the One Washington financial status report. The creation of
this report includes: gathering financial data, making any necessary adjustments to the projected spend;

03/10/2021
analyzing significant variances and identifying areas of concern, especially those that would require action by the
program.
The report, along with the budget manager’s narrative, are provided to the executive director for review and
discussed with the leadership team. The executive director and/or leadership team will identify any areas of
concern that need to be addressed and take appropriate action
5.10 Agency Pool Funds

This section describes how One Washington plans to administer agency pool funds.
5.10.1 Agency OCM Pool

This pool will provide agencies with organizational change management resources to prepare and support
leaders and staff (IT and business) with the changes resulting from the Workday ERP: before, during, and after
implementation.
Using tools and templates provided by One Washington, these OCM SMEs will support agency-level readiness.
These resources will develop customized OCM plans specific to agencies. The resources will handle the
development, coordination, organization, facilitation and deployment of agency-specific OCM plans in order to
ensure successful adoption of the Workday ERP.
For more information, please refer to the Deloitte OCM Funding Pool Plan (OCM SOW 2 deliverable 7).
5.10.2 One Washington Technology Pool

The One Washington Technology Pool is intended to provide agencies with funding to assist with technical
support for a successful ERP implementation. It is separate and distinct from the previously mentioned Gated
Funding OCIO IT pool.
The One Washington technology pool is critical for providing agencies the skills, expertise and resources to
modify their systems and interface to the One Washington ERP. This pool will be administered by the One
Washington program, in collaboration with OCIO and OFM Budget, to ensure agencies only use these funds for
the work needed to effectively connect the agency systems to the new ERP and ensure data quality and integrity.
For detailed information on how One Washington plans to administer these funds, see the One Washington
Technology Pool Process Framework document.
5.10.3 OCIO-gated Funding Pool

One Washington is an IT project under gated funding oversight by the Office of the Chief Information Officer
(OCIO) and the Office of Financial Management (OFM). The 2019 legislature passed new Information Technology
oversight requirements, which includes a requirement for state agencies whose IT projects are subject to the
Office of Chief Information Officer’s Gated Funding oversight, please see Section 719 of the 2019-21 operating
budget for more information.

03/10/2021
State agencies are required to develop a technology budget and investment plan for each information
technology project subject to oversight. The technology budget’s purpose is to plan and track financial
information from project initiation through project closeout. The strategic plan, including resources and schedule
identified in the investment plan (IP) should align with the technology budget. The gated funding oversight
process is a version of the standard OCIO approval and oversight process with the additional element of gated
funding. The gated funding oversight structure tracks project status in stages, based on project’s scoped
deliverables and the project’s financial elements, the technology budget, the investment plan, and the IT pool.
• The technology budget must be submitted using the standard template and format. At each gate, the
project will apply to OCIO and OFM to receive funds for the next project stage.
• The investment plan is an OCIO required project document that summarizes the project description,
business benefits, scope, acquisition plan, schedule, project governance and management plan, budget,
dependencies and risks.
• The OCIO IT oversight may also be referred to as the IT Pool, which refers to the information technology
investment revolving account created in RCW 43.41.433, a state fund where allocated money is held
before it is allotted to specific IT projects.
Effective July 1, 2019, state agencies must use the technology budget Excel workbook template that is available
on the OCIO website. When submitting a technology budget, the One Washington program will align with the
approved standard naming convention format: OFM_One Washington_Phase_TechBudget_yyyymmdd
5.11 Funding Oversight

One Washington will follow all OCIO established procedures for review, approval, and oversight as referenced on
the OCIO homepage .
Per OCIO Policy 121: IT Investments – Approval and Oversight Policy and OCIO Policy 121 – Procedures, the One
Washington program is a Level 3 IT investment and considered a major IT project that is subject to OCIO
oversight.
Typically, OCIO oversight IT projects will receive 85% of their funding at the beginning of each gate with the
remaining 15% provided at the end of the gate after the gate and associated deliverables are certified. However,
in the 2020 Operating Budget—Supplemental (ESSB 6168), One Washington’s gate withhold percentage was
changed from 15% to 20%.
5.11.1 Technology Budget Components

The technology budget outlines the project budget and spending plan for the gated funding project. The
following items must be included within the technology budget:
• Budgeted resources: Detailed outline of how the project intends to use its’ current funding, including
base funding, for the duration of the project. Includes staff, IT hardware, software, IT services,
professional contracted services and labor. These are typically for resources beyond an agency’s baseline
capability and/or capacity. Therefore, is excludes any in-kind resources.

03/10/2021
• In-Kind resources: Existing resources committed to the project at no additional cost to the project as
well as One Washington’s base funding.
• Full-time equivalent (FTE) staffing levels (either budgeted or in-kind): Identifies the percent of FTE
classification type and number of individual State staff positions budgeted and expended.
o Position Title/Job classification: The job classification title and numerical range associated with it.
See Compensation and Job Classes for more information.
• Required Financial Budget/Account Coding Elements: State agencies are mandated in the 2019-21
operating budget to report a minimal set of data elements for their projects to allow stakeholders to
generate reports and track project expenditures.
• Anticipated deliverables: Identifies and tracks deliverables to complete at each gate separately and their
cost, which should closely align with the activities identified in the Investment Plan. Project deliverables
are identified, by the One Washington project management team, from the project schedule.
5.11.2 Gated Funding Application

One Washington will apply for gated funding of the approved technology budget through the OCIO gated
funding application. Once the technology budget and related investment plan have been approved by the OFM
budget assistant, IT Project Oversight and the program’s assigned OCIO consultant, the budget manager will
complete the OCIO Gated Funding Application and submit to the appropriate OCIO consultant and the OFM
budget assistant, IT Project Oversight to formally request funding for the applicable gate. The OCIO consultant
will recommend to OCIO leadership that the technology budget and investment plan be approved, and the gate’s
funding be released. If approved, the program will receive a formal letter releasing: 1. the prior gate’s 20%
withheld funding and 2. 80% of the current gate’s funding.
Once the program receives the OCIO approval letter, the budget manager will coordinate with its’ OFM budget
assistant and OFM finance to allot the approved funding. After the funding has been allotted, the budget
manager will review the program’s expenditures for the applicable gate and make any necessary corrections,
including adjusting chart of accounts coding, via journal voucher and/or payroll forms, for expenditures incurred
during the applicable gate.
5.12 Technology Budget Changes

A material change to an existing posted, OCIO and OFM approved technology budget for a project reflecting
changes in scope, schedule, budget, gates and/or deliverables requires a technology budget amendment.
A non-material change to an existing posted, OCIO and OFM approved technology budget is used to make
technical corrections only. Corrections may include a change in project point of contact, updates to deliverable
completion dates, updates to target completion dates for upcoming deliverables, corrections to AFRS codes to
reflect costs, etc.
5.13 Cost Management Glossary of Key Terms

This section summarizes key concepts and terms used as part of Cost Management for the One Washington
program.

03/10/2021
Program Budget: the cost estimate for the program, funding requested and received by an agency during the
specified biennium. The One Washington’s budget is divided into subprojects based on phases, which is
reflected in its Technology Budgets.
Washington State budgets are based on a two-year (biennial) state fiscal period. The Washington state biennium
runs from July 1 of an odd-numbered year to June 30 of the next odd-numbered year. A fiscal year is the State
12-month period that runs from July 1 through June 30 of the following year and is named for the calendar year
in which it ends. For example, the 2021-23 biennium includes both:
• Fiscal year 2022 that begins July 1, 2021 through June 30, 2022
• Fiscal year 2023 that begins July 1, 2022 through June 30, 2023
One Washington will also provide forecasts for maintenance and operations (M&O) costs. Annual M&O costs
are costs associated with the ongoing support of an IT investment after project closure and/or transition to
operations.
M&O costs are not typically reported within technology budgets, but the One Washington was directed to add
this information as part of the gated funding process.
Contracted Professional Services: the amounts that are planned/budgeted for contracted resources, regardless
of how they are acquired (e.g., request for proposals, direct buy, agency convenience contract, inter-agency
agreement); applies to all planned consulting.
Non-state Employee Staffing Costs: contractor or external labor needed to complete the scope of the project.
Software Licenses and Subscriptions: the amounts expended for purchased software or licenses of commercially
available software with a useful life of one year or less, including upgrades and/or maintenance agreements.
Software licensing includes, but is not limited to, the right to use the software, support for the software and
upgrades.
State Employee Staffing Costs: the full cost to employee state staff. Includes salary, benefits, and other costs
associated with an employee (travel, supplies, indirect costs-IT, HR and Accounting support).
Funding Source(s): the different funds the agency is drawing from to provide financial support for the project,
referring to chart of accounts coding used to identify the source of allocated project funds (e.g., general fund
state, general fund federal, statewide IT system maintenance). This information is available within the Fund
Reference Manual on the OFM website.
Object: a state accounting classification used to categorize expenditures. Objects of expenditure in the State
operating and capital budgets are:
 Object A: Staff salary

 Object B: Benefits

03/10/2021
 Object C: Contracts
 Object E: Goods and services
 Object G: Travel
 Object J : Equipment
 Object T: Intra-agency reimbursements
Sub-object: a refined breakdown of Object of expenditures relating to particular items or item categories.
Section 75.70 of the Statewide Accounting Administrative Manual (SAAM) is the source for object and sub-object
codes.
Carry-forward Level (CFL): a reference point created by calculating the biennialized cost of decisions already
recognized in appropriations by the Legislature.
Maintenance Level (ML): reflects the cost of mandatory caseload, enrollment, inflation and other legally
unavoidable costs not contemplated in the current budget. Expenditure adjustments may be positive or
negative, depending on expected experience in the ensuing biennium.
Policy Level (PL): incremental expenditure changes that do not fall under the definitions of CFL or ML are
considered PL changes. These changes may represent revised strategies or substantial differences in program
direction, and can include proposed program reductions. Each significant change to current policy must be
justified in a DP.
Contingency: events that could affect the execution of the project and impact success, may be accounted for
with a contingency reserve (money allocated in cost baseline for known risks with mitigation strategies).
Cost Aggregation: summarizes lower-level cost estimates associated with various components of the project.
Cost Variance (CV): the amount of budget deficit or surplus at a given point in time, expressed as the difference
between budgeted and actual costs.
Forecast: estimate or prediction of conditions/events in project future, based on information and knowledge
available at the time of the forecast.
Funding Requirements: forecasts project costs to be paid, derived from cost baseline for total or periodic
requirements, including projected expenditures plus anticipated liabilities.
OFM Budget Terms: a glossary of terms related to the OFM Budget that can be found on the OFM website.
Technology Budget Glossary of Terms: a glossary of terms related to Technology Budgets can be found on the
OCIO website. This plan uses standard Washington state enterprise and basic project management terminology.
Threshold: pre-determined value of a measurable variable that represents a limit that will require certain actions
to be taken if it is reached.

03/10/2021
6. RAID Management Plan
6.1 RAID Introduction

This section of the Playbook describes the “project controls” processes, tools, and responsibilities One
Washington project team members will have to properly and effectively identify and manage projects risks,
action items, issues, and decisions (RAID) on the project. Each type of control is presented in this section, in the
order they follow in the “RAID” acronym.
6.1.1 RAID Tool

The One Washington project will be using Project Management Center (PMC), Deloitte’s web-based
management tool that is a customized version of the MicroFocus Project and Portfolio Management (PPM)
application that has been a market-leading PM tool for over a decade. PMC will provide the One Washington
project a “single source or truth” to log and manage RAID tickets (called “requests” in PMC) accurately,
consistently, and effectively throughout the project. The diagram below highlights the benefits of PMC:
Figure 11. PMC RAID Tool Project Management Benefits

03/10/2021
6.1.1.1 One Washington Custom PMC Fields

The PMC tool has four (4) General Settings fields that can be customized with project-specific pull-down options
and descriptions. The One Washington PMO has configured these custom fields the following way (see below).
These fields can be further adjusted/configured:
(1) Releases: Currently four (4) entries for the One Washington Project:
Figure 12. PMC Release Custom Settings
(2) Teams: Currently eleven (11) entries for the One Washington Project:
Figure 13. PMC Team Custom Settings

03/10/2021
(3) Phases (Stages): Currently six (6) entries for the One Washington Project:
Figure 14. PMC Phase Custom Settings
(4) Discipline/Threads (i.e., Workstreams): Currently eight (8) entries for the One Washington Project:
Figure 15. PMC Workstream Custom Settings
All four of these custom fields are optional (not mandatory) per PMC requirements when logging a request/RAID
item. However, selecting a value for each of these custom fields when logging and managing tickets will enable
the One Washington PMO and project leadership to sort and/or filter RAID tickets for reporting in many ways
that would NOT be available otherwise.

03/10/2021
Thus all One Washington project team members are expected to select values for this four custom One
Washington fields every time they create a new RAID ticket, or are managing RAID tickets assigned to them and
find blanks in these fields.
Custom One Washington fields in PMC for Release, Team, Phase (Stage) and
Discipline/Threads (Workstreams) are mandatory when creating and managing PMC RAID
tickets.
6.1.2 RAID Roles and Responsibilities

Below is a table that outlines the roles and responsibilities regarding One Washington RAID items on the project.
Please refer to the previous Governance Plan section for information regarding decision-making authority levels
and escalation procedures, as well as understanding the roles and responsibilities of the program’s different
governing bodies.
Table 20. RAID Roles and Responsibilities
All One Washington  Identify and log One Washington RAID items into PMC as they are
project team members encountered throughout the project lifecycle
 Work with the RAID owners when input is needed to help address
and/or manage a RAID item to closure
 Properly manage RAID items assigned to closure in a timely,
appropriate manner, keeping the ticket record for each RAID item
up-to-date and complete
One Washington PMO  Continuously monitor and ensure that all appropriate RAID items
are properly logged in PMC as accurately and completely as
possible, depending upon its workflow status and requirements at
each workflow stage
 Convene workgroups with the appropriate stakeholders and/or
SMEs to brainstorm resolution steps or risk response strategies and
response plans, as appropriate
 Prepare weekly RAID Dashboards for status reporting and
meetings, highlighting delinquent and/or critical priority tickets
 Plan and conduct regular reviews of high-priority RAID tickets
 Follow Governance Plan guidelines and protocols to escalate
priority RAID items as appropriate
 Monitor RAID items and confirm tickets that should be closed or
cancelled as appropriate

03/10/2021
RAID Ticket Owners  Work with appropriate team members and the PMO to fully assess
assigned RAID tickets and their impacts, as well as resolution or
mitigation plans
 Where appropriate, conduct a root cause analysis of an issue to
understand its source and help define an effective resolution
 Analyze risks and their risk scores to determine to the right
response strategy (i.e., avoid, transfer, accept or mitigate) and
response plan
 Actively manage all assigned RAID items on a weekly basis, and
keep their PMC information and status as up-to-date and complete
as possible
 Provide timely responses to questions or other information
requests on assigned RAID items from other team members,
stakeholders, the PMO or Governance bodies
 Inform the PMO when RAID items meet the criteria for escalation
(see the Governance section in this Playbook for more information)
Workstream/Team Leads  Monitor and validate respective team RAID tickets
 Be responsive and communicate team positions/views on RAID
tickets impacting respective workstream(s)
 Work with assigned RAID owners to help assess impacts, causes,
resolutions, risk responses, or feasible decision options, as
appropriate
 Assist in the coordination and execution of relevant risk plans if the
risks are realized
 Inform the PMO when RAID items meet the criteria for escalation
(see the Governance section in this Playbook for more information)
Business Transformation  Advise and provide recommendations for risk mitigations,
Board (BTB) response plans, and status to the program director,
program team leads, project managers, and PMO
 Approve or reject RAID analysis and response or resolution
recommendations for all RAID items escalated to the BTB
 Determine subject matter experts and gather needed
inputs from them, as required
 Determine if and when a RAID item needs to be escalated
to the ESC, in accordance with the Governance Plan
guidelines and protocols
One Washington Program  Ensure accountability of all roles within the RAID management process
Director  Provide resources and support needed for the development and
implementation of the RAID management processes
 Authorize the execution of risk response plans, as required
 Escalate priority RAID items that cannot be controlled at the program
level to the appropriate governance body
 Work within the governance structure to mitigate
enterprise-wide and external stakeholder risks, as needed

03/10/2021
Executive Steering  Advise and provide recommendations for escalated RAID items to the
Committee (ESC) program director, program team leads, project managers, and PMO
 Approve or reject RAID analysis and response planning/resolution/decision
recommendations for all RAID items escalated to the ESC
 Seek input from subject matter experts, as needed
 Work with the executive sponsor to mitigate enterprise-wide or external
stakeholder risks and issues, as needed
 Authorize contingencies and communicate actions, as needed
One Washington  Advise and provide direction to the ESC and BTB, as required
Executive Director  Approve or reject RAID analysis and response planning/resolution/decision
recommendations for all RAID items escalated to the executive sponsor
 Seek input from subject matter experts, as needed
 Work with the One Washington Executive Director to mitigate enterprise-
wide or external stakeholder risks and issues, as needed
 Authorize contingencies and communicate actions, as needed

03/10/2021
6.2 Risk Management

A risk is an uncertain event or condition that can negatively impact the One Washington project objectives
and/or outcomes. The PMBOK® Guide also describes positive risks to a project; however, in One Washington
project parlance, a “risk” connotes a negative potential impact or condition for the project; never positive.
6.2.1 Risk Process Summary

The flowchart 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
Figure 16. One Washington Risk Process
6.2.1.1 Identify and Analyze Risk

Throughout the project, One Washington team members should identify risks that can negatively impact project
outcomes. The Risks Log for this project will be in PMC.
 Risks are identified during weekly project status meetings, or the bi-weekly or special RAID meetings
organized by the project manager or PMO manager
As risks are identified, the following information will be captured:

03/10/2021
 Project
 Assigned To (“risk owner”) – the project team member responsible to develop and implement the risk
response plan
 Status – the status of the risk as it flows through the process (Risk status is assigned automatically within
PMC)
 Priority – a subjective assignment of the significance of the risk used by the project manager for
prioritization and status reporting. The priority risk ratings for the project are as follows (Priority can be
used to further prioritize risks in cases where there are multiple “High” severity risks.):
o Critical— the risk response plan must be defined and executed immediately
o High— the risk response plan must be defined and executed as soon as possible
o Medium— the risk response plan can be developed any time before the next risk review meeting
o Low— a risk response plan is not required
 Type – a means for categorizing risks (see subsequent section for type options and descriptions defined
in PMC)
 Probability – the likelihood of the risk occurring
 Impact – the overall impact if the risk does occur
 Severity – probability times impact (automatically calculated - see subsequent section for details)
 Short Description – a brief description of the risk
 Due Date – sometimes referred to as the risk’s trigger date or timeline, this represents the forecasted
date when a risk may be realized or project events may change its probability and/or impact. This date
will be used by PMC to monitor whether the ticket is late, and it will show up in late ticket (called
requests) reports once the current date is > the due date defined for the risk ticket
 Long Description – a more detailed description of the risk
 Open Issue on Close? – PMC has an option for the workflow to automatically prompt the user to create a
new issue request/ticket when a risk is realized, and will transfer over all relevant information from the
risk ticket to the new issue ticket. The user will have the option of bypassing this new issue trigger (if it’s
no longer valid) when the risk is realized, so the ticket can just be closed and the approved response plan
will be implemented
The objective of the risk analysis is to develop more specific information to aid in decision-making during the
response planning or resolution process. The analysis of risks and issues is a crucial step for determining how
they might impact the program.
The risk owner/assignee may identify additional business and technical subject matter experts to become
workgroup members and set a due date to complete the response plan. An owner may re-assign the risk
probability and impact ratings based upon inputs from the business and technical members of the workgroup,
thereby changing the risk severity score and potentially the risk response plan required.
6.2.1.2 Develop Risk Response

For “High” severity risks, 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 strategy (more details below):

o Accept – accept the risk, but monitor it
o Avoid – devise a strategy to avoid the risk
o Mitigate – determine actions to eliminate or reduce the risk

03/10/2021
o Transfer – transfer the risk responsibility to another group
 Response plan – 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
The risk response strategy is a process of identifying strategic options and determining actions, to enhance
opportunities and reduce threats to the project's objectives. Response planning covers three general strategies:
1) Reduction – identifies ways to minimize or eliminate project risks. The risk owner is overall
responsible for developing options and determining actions to lessen impacts or threats to the
program. Risk reduction strategies include:
 Avoid – involves changing the project plan to eliminate the threat posed by the adverse
risk.
 Transfer – requires shifting the negative impact of a threat along with the ownership of the
response to a third party. Transferring the risk simply gives another party responsibility for
its management: e.g., insurance is a good example of transferring risk to the insurance
company…for a price.
 Mitigate – reduce the probability and/or impact of a risk event to a more acceptable level.
2) Acceptance – risks can be accepted as is or after mitigation steps have been taken. Risks are
typically accepted when a mitigation plan has not eliminated the risk, and/or the cost/benefit of
eliminating the risk is not acceptable.
 Contingency reserves may be established for risks, including amounts of time, money or
other resources necessary to respond to a realized risk.
 Accepted risks are monitored and if realized, outcomes will be addressed by the project
team.
3) Contingency planning: defines a back-up or “Plan B” for a realized risk if the approved response
plan does not work or reduce the impact as much as expected.
Once the risk owner completes his/her risk assessment and proposed risk response strategy and response plan,
the PMO will determine who needs to review and approve the response plan, and arrange a meeting to review
if/when required: e.g., the risk’s severity score and/or priority is “Critical” or “High” and the appropriate
Governance body will need to review and finalize the risk strategy, response plan, and contingency (i.e.,
“backup”) plan for the risk.
The PMO will also work with the risk owner, when needed, to convene a workgroup to explore mitigation
strategies and recommendations. The PMO is responsible for working with the risk owner and other
stakeholders to ensure that the risk assessment is complete and well documented.
Risks at this workflow stage will be designated as “In Progress” status in PMC during this process. When
necessary, the PMO manager will escalate to the appropriate governance level for review and analysis, per the
process defined in the Governance Plan section this Project Management Playbook.
6.2.1.3 Monitor Risk

The project manager, PMO manager, team leads and risk owner monitor the risk throughout the life of the
project, for as long as the risk remains relevant to the project and is in active (i.e., “In Progress”) status.
 Determine the appropriate new risk owner(s) if the risk assignment needs to change
 Where necessary, update the risk score, assessment, response, or other details

03/10/2021
 Determine if or when a risk needs to be escalated to the next Governance level
6.2.1.4 Determine if Risk is Realized

As part of risk monitoring, the project manager, PMO manager, team leads or risk owner determines whether
the risk has been realized on the project.
 For realized risks, follow the risk realization steps included in the approved risk response plan (where
applicable), and log a new issue in PMC for the realized risk, where appropriate.
o As mentioned above, this create issue option can be bypassed if it is not relevant
 Once the issue record is created, cross-reference the new Issue # 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 or “In Progress.”
6.2.1.5 Manage Issue

For a realized risk that converts to a project issue, address it using the project’s standard issue management
process.
6.2.1.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, adjusting its probability/impact, response plan,
and escalating when necessary
6.2.1.7 Close the Risk

Set the risk record status to “Closed” by clicking the “Risk Realized” button in PMC.
6.2.2 Risk Types

The following risk types will be used to categorize identified risks in the Risk Log.
Table 21. Risk Types
Risk Type Risk Type Description

Contract Any risk related to the contracts of the project (such as a signed agreement between Deloitte
and One Washington or subcontractors).
External Any risk related to environmental factors largely outside the control of the project (such as
cultural, legal, or regulatory).
Financial Any risk related to the budget or cost structure of the project (such as increase or decrease in
the project-related budget).
Functional Any risk related to the overall function of the product (such as requirements or design) being
developed by the project.
Quality Any risk related to the quality requirements of the project.
Organization Any risk related to internal, One Washington, or third-party organizational or business changes
(such as executive leadership role changes).
Performance Any risk associated with the performance of the application (such as response time, stress
testing, and development environments).

03/10/2021
Risk Type Risk Type Description

Project Any risk related to the management of the project (such as communications, status reporting,
Management and issues management).
Resource Any risk related to project resources (such as the addition or removal of resources).
Schedule Any risk related to the Work Plan and related tasks (such as extensions or reductions of the
project timeline).
Scope Any risk related to project scope (such as process, module, and development objects).
Technical Any risk related to software or hardware, including infrastructure related to the project.
General Any risk that cannot be categorized into one of the above categories.
6.2.3 Risk Severity Scoring

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 estimated by the risk creator and analyzed/verified by the risk owner, who
may need to bring in relevant subject matter experts or business owners to help with the analysis and
assessment. Formal, properly vetted risk response plans are required for risks determined to be High severity,
and recommended for most Medium severity risks. Other risks will be monitored and reviewed, but will not
necessarily require a formal risk response plans, particularly if the risk response strategy is “Accept” the risk.
Proper risk response planning and monitoring will be done by the PMO.
If the risk or issue solution or remediation has an impact to project scope, budget, quality, or schedule, a change
request may be generated. Please refer to the Scope Management and Change Control Plan section for the
change request process. Risks with high and medium severity should also have a contingency plan as a back-up
to the risk response plan.
Table 22. Risk Severity Scoring
Impact Probability
1-Low 2-Low/Medium 3-Medium 4-Medium/High 5-High
5-High Low (5) Medium (10) High (15) High (20) High (25)
4-Medium/High Low (4) Medium (8) Medium (12) High (16) High (20)
3-Medium Low (3) Medium (6) Medium (9) Medium (12) High (15)
2-Low/Medium Low (2) Low (4) Medium (6) Medium (8) Medium (10)
1-Low Low (1) Low (2) Low (3) Low (4) Low (5)

03/10/2021
Score Severity
1-5 Low
6-12 Medium
13-25 High
6.2.4 Risk Monitoring

Active risks will be tracked and published in the weekly and monthly leadership status reports. PMC has pre-
configured risk reporting available through its risk manager dashboards and portlet tables that can be easily
configured for specific and or changing One Washington risk reporting requirements. The risk dashboards can
also be easily exported into a PDF file or excel file for further manipulation and/or copy/paste into a status
report.
A realized risk will: (1) Initiate the approved response plan defined for the risk (where applicable); and (2) may
create a new issue in PMC, to follow the issue management process described in a subsequent section. If the
realized risk does not become an issue, it can be closed after its response and/or contingency plan is fully
implemented and completed.
The following risk measurements are default risk status metrics offered in the standard PMC risk manager
dashboard and will be used to monitor and control One Washington project risks:
 Risks by status
 Risks by priority and status
 Active risks by priority
 Active risk aging by priority
6.3 Action Item Management

This section documents the process the One Washington project will use to log and manage action items to
closure in PMC, throughout the life of the project. An action item is an assignment to do some work or address
a question on the project that is NOT part of a task or step defined in the project schedule.
The next section further delineates when an action item should be logged and tracked in PMC.
6.3.1 When to Log Action Items in PMC

As a guideline, a One Washington task should only be logged/assigned as an action item in PMC when it meets
the following criteria:
 It is an assignment to do some work or address a question that requires cross-workstream/team input

and be accomplished in eight hours or less total effort
Assignments of similar short tasks (i.e., 8 hours or less) that stay within a single workstream or One Washington
team can be documented and managed using the Planner Kanban boards described in the Schedule
Management section of this Playbook.

03/10/2021
Any task that requires more than one working day’s effort (i.e., 8+ hours) should be addressed by a task in the
Project Schedule; or there should be a change request (CR) to add it to the Project Schedule if it is not addressed
– please see the Scope Management and Change Control Plan section for more information.
6.3.2 Action Item Process Summary

The flowchart below summarizes the action item management process/workflow in PMC that will be used when
cross-workstream/team action items are logged for the One Washington project:
Project
Management
Plan
1. Create Action 2. Perform Action 3 . Action Item 4. Close Action

Ready to Close?
Yes
Item Item Item
No
Action Items Log
Legend
Inputs / Supporting
Figure 17. One Washington Action Item Process
6.3.3 Action Item Priorities

Below are the action item priorities and descriptions configured into PMC:
 Critical - the action item must be addressed immediately in order to protect the project's objectives
 High - the action item must be addressed as soon as possible in order to prevent significant negative
impacts to the project (for example, cost overruns or milestone delays)
 Medium - the action item will be addressed, monitored, and controlled following regular project action
item management processes
 Low - the action item will be addressed as cost and schedule permits
These priorities and descriptions are provided in PMC as online Help for action items.
6.4 Issue Management

An issue is an event or situation that has occurred, was not planned, is negatively impacting the project and
requires action to resolve. Issues can also be known as problems, gaps, or conflicts. Additionally, a risk that is
realized can also become a project issue.

03/10/2021
6.4.1 Issue Process Summary

The flowchart below summarizes the issue management process/workflow followed in PMC:
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
Figure 18. One Washington Issue Process
6.4.1.1 Create Issue

One Washington project team members identify issues impacting the project and document them in PMC. 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 issue.
Required fields include:
 Project
 Assigned To
 Priority
 Type
 Description
 Detailed Description
The issue status tracks the status of an issue as it flows through the process. The PMO will review and validate
“New” issue status records from the project team, canceling any new issue entries that are not valid. The PMO
will also confirm or re-assign valid issues to the appropriate project team member(s) (issue owners) for detailed
analysis and resolution planning.

03/10/2021
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:
 Priority – the priority issue ratings for the project are as follows:
o Critical – the issue is jeopardizing overall project objectives and must be addressed immediately
o High – the issue is negatively impacting the project significantly (for example, cost overruns or
milestone delays) and must be addressed as soon as possible
o Medium – the issue is negatively impacting the project and should be addressed, monitored, and
controlled using regular project issue management processes
o Low – the issue has minimal impact and should be addressed as cost and schedule permits
 Type – Issue types are defined in a table below
 Project areas and stakeholders impacted: Release, Team, Phase, Thread, Stakeholder(s)
 Resolution, including:
o Escalation Level
o Resolution
o Whether a change request (CR) needs to be created to close the issue
o Other closure criteria
For “Critical” or “High” priority issues, the PMO managers should review and approve the proposed issue
resolution for each.
6.4.1.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.
o Work with the PMO if escalation is required
6.4.1.3 Change Request Required to Resolve Issue?

The issue owner determines whether 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 create a change request to resolve the issue.
6.4.1.4 Manage Issues

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 PMO and appropriate governance body.
 Issue CRs that are not approved will need to be set to “Closed” or “Cancelled” status, as appropriate.
6.4.1.5 Close Issue

Confirm that the resolution steps completed resolved the issue successfully.

03/10/2021
 The appropriate stakeholder(s) identified for the issue should help confirm the issue resolution.
 For issues where resolution is confirmed, click on the “Resolve Issue” button in PMC to set the issue to
“closed” status.
 Issues where the resolution results were not confirmed will remain in “In Progress” status until they can
be successfully confirmed.
6.4.2 Issue Types

The table below presents the issue types that are defined in PMC. These types are not allowed to change in PMC,
and this is a required field when logging an issue:
Table 23. Issue Types that are defined in PMC
Issue Type Issue Type Description

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

Unresolved Critical and High priority issues will be reported in the weekly and monthly status reports; medium
issues greater than 1 week past due will also be reported. Unresolved Critical and High priority issues will be
escalated by the PMO.

03/10/2021
The following issue measurements are provided by the standard default Issue Manager Dashboard available in
PMC to effectively monitor and control One Washington project issues:
 Issues by status
 Issues by priority and status
 Active issues by priority
 Active issue aging by priority

03/10/2021
6.5 Decision Management

Decisions are project situations where a team lead or management has two or more options when determining a
project approach or choice that will impact future work and/or outcomes on the project. If there is an active
problem negatively impacting the project, that should be logged as an issue that needs resolution, not a project
decision. The issue owner may come up with resolution options and need to select the best one, but that is still
in context of managing the issue to closure.
Managing project decisions includes identifying, documenting, prioritizing, assigning, and tracking the results of
decisions throughout the phases of the project. This section documents the process and tools the project will use
to log and manage day-to-day decisions, as well as formal, high-impact project decisions.
Day-to-day decisions are decisions that the PMO deems necessary to document and track for future reference.
Formal decisions are decisions that meet the criteria defined below and require a more structured process for
analyzing alternatives for potential solutions. The decision criteria for making a formal decision versus a day-to-
day decision must be understood by all One Washington project team members.
6.5.1 Decision Process Summary

The flowchart below summarizes the decision management process/workflow followed in PMC:
Project
Management
Plan
No
1. Identify and 2. Formal

3. Perform
Document Decision Yes
Required? Formal Decision
Decision
No
6. Proposed 7. Communicate
4. Assess 5. Make
Recommendation Yes and Implement
Alternatives Recommendations Approved ? Decision
Decisions Log
Legend
Inputs / Supporting
Figure 19. One Washington Decision Process

03/10/2021
6.5.1.1 Create Decision

One Washington project team members identify decisions impacting the project and document them in PMC.
Any project team member can identify a project decision at any point in the project lifecycle.
The person identifying and logging the decision needs to provide as much information as possible on the new
decision. Required fields include:
 Project
 Assigned To
 Priority
 Type
 Description
 Detailed Description
The decision tracks the status of a decision as it flows through the process. The PMO will review and validate
“New” decision status records from the project team, canceling any new decision entries that are not valid. The
PMO will also confirm or re-assign valid decisions to the appropriate project team member(s) (decision owners)
for detailed analysis and decision recommendations.
The assigned team member(s) will confirm or define the following fields for a decision record after completing
the necessary due diligence and analysis on the decision:
 Priority – the priority decision ratings for the project are as follows:
o Critical – The decision has overall project outcome ramifications and must be addressed
immediately.
o High – The decision has significant project ramifications (for example, impacts project budget,
quality, or milestones) and must be addressed as soon as possible.
o Medium – The decision has project ramifications and should be addressed, monitored, and
controlled using regular project decision management processes.
o Low – The decision will have minimal impact and can be addressed as cost and schedule permits.
 Type – Decision types are defined in a table below
 Project areas and stakeholders impacted: Release, Team, Phase, Thread, Stakeholder(s)
 Escalation level
6.5.1.2 Day-to-Day Decision-making Process

Although most project decisions do not require a formal decision process, using a detailed qualitative and
quantitative analysis of alternatives, important project decisions should be logged in PMC and managed to
closure, similar to risks, issues, and action items.
The objectives of the day-to-day decision-making process include:
 Documenting and communicating key, impactful day-to-day decisions made

 Confirming that day-to-day decisions are made in a timely manner
 Preventing decisions made from being revisited
Day-to-day decisions should be documented in PMC with a documented Proposed Decision and Rationale, at a
minimum, in order to be approved and closed.

03/10/2021
6.5.1.3 Formal Decision-making Process

Decisions that meet the formal decision criteria defined below are decisions that may impact project outcomes
regarding the solution schedule, cost, or quality. It is critical that formal decisions be made once, by the right
level of governance authority, and in a timely manner.
The formal decision-making process allows the project team to analyze possible critical decisions using a formal
evaluation process that evaluates identified alternatives against established criteria. The formal decision process
results in a recommended solution and rationale that are provided to key stakeholders for review and approval
before it is considered final.
The objectives of the formal decision-making process include:
 Making decisions using qualitative and quantitative feedback based on established solution criteria at
the appropriate level of authority
 Driving timely decision-making
 Documenting and communicating formal decisions made
 Preventing formal decisions from being revisited
The table below lists some examples of the types of project decisions where the formal decision-making process
should be used, and includes the approval authorities for each decision type. In addition to these types of
decisions, the project should consider using the formal decision process in scenarios where the outcome may
significantly impact the ability of the project to meet its commitments or established objectives.
Table 24. Examples of the types of project decisions
# Formal Decision Scenario Approval Authorities

1 One Washington Program ESC, Program Directors, Budget Manager, Advisory Committee Chairs,
Roadmap and Release PMO managers
Strategy
2 Foundational Data Model ESC, Program Directors, Budget Manager, Advisory Committee Chairs,
(FDM) Strategy and Approach PMO managers
3 One Company versus Agency Program Directors, BTB, relevant Advisory Committee members, PMO
Process managers
4 Tool selection Program Directors, Budget Manager, Chief Technology Officer, PMO
managers, workstream/team lead(s)
5 Key architectural decisions Program Directors, Budget Manager, Chief Technology Officer, PMO
with multiple options managers, workstream/team lead(s)
The Formal Decision Alternative Evaluation Tool allows decision reviewers a structured template to rate, score
and compare decision alternatives against defined criteria, thereby enabling both qualitative and quantitative
analysis. The tool can be used to help generate a recommended solution with backing rationale to present to key
stakeholders for final review and approval of the recommended decision.

03/10/2021
The project’s Formal Decision Alternative Evaluation Tool can be found here: <Provide link to the project’s
Formal Decision Alternative Evaluation Tool when available.>
For “Critical” or “High” priority decisions, the PMO managers should review and approve the proposed decision
recommendation and rationale, as well as the decision approver, before taking the decision to the appropriate
Governance body.
6.5.1.4 One Washington Prioritization Criteria for Making Decisions

Regardless of whether the project is making a day-to-day decision or a formal decision, the decision owner/team
should evaluate their decision keeping the prioritization criteria defined for One Washington in mind as part of
their analysis.
The Prioritization Criteria Framework shown below is a helpful way to organize and categorize project decisions
against key program criteria highlighting the mission and goals of the One Washington initiative: high impact
toward initiative objectives with low/reasonable difficulty in implementing.

03/10/2021
Figure 20. One Washington Prioritization Matrix for Project Decisions

03/10/2021
6.5.1.5 Accept/Close or Reject Decision

The decision owner submits the recommended decision for approval to the decision approver.
 Approver Approves or Rejects the recommended decision

 Approved decision ticket is Closed
 Rejected decision goes back to “In Progress” status for another round of evaluation, analysis of options,
and recommended decision; or it can be cancelled
 If the decision cannot make progress, escalate the decision
6.5.2 Decision Types

The table below presents the decision types that are defined in PMC. These types are not allowed to change in
PMC, and this is a required field when logging a decision:
Table 25. Decision Types
Decision Type Decision Type Description

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

03/10/2021
6.6 RAID Meetings

Key One Washington project team leaders meet bi-weekly to review and add/update RAID items. This meeting
schedule is created and managed by PMO team member Matthew Toney. The table below describes additional
details regarding the bi-weekly RAID meeting.
Table 26. RAID Meetings
Meeting Logistics Project Plan

Meeting Frequency and Schedule  Bi-weekly
Participants  PMO managers, team leads, and PMO team
Attendees needed for a Quorum  4 people, including at least one PMO manager
Meeting Agenda  Review active RAID tickets to determine if any parameters have
changed, or whether any tickets can be closed
 Identify new RAID items (for risks, should include preliminary
probability and impact)
 Assign responsible owners for new RAID tickets
 Review drafts of any new risk response plans, resolution plans
(for issues), or proposed decisions for any of these items with
High or Critical priority, or Medium priority and marked as Late
 Determine if any RAID items need to be escalated
After each RAID review meeting, the PMO has the following responsibilities:
 Update PMC to record RAID ticket changes and/or additions

 Communicate the updated RAID status
6.7 RAID Management Glossary of Key Terms

Table 27. RAID Management Glossary of Key Terms
Term Definition
Risk  An uncertain event or condition that, if occurs, has a .negative effect on one or more of the
program’s objectives.
Action Item  An assignment to do some work or address a question that requires cross-workstream/team
input and be accomplished in eight hours or less total effort.
Issue  An event or situation that has occurred, was not planned, and requires action. Issues may also
be referenced as problems, gaps, or conflicts. Additionally, a risk that is realized can also
become an issue.
Decision  A project situation where a team lead or management has two or more options when
determining a project approach or choice that will impact future work and/or outcomes for
the project.

03/10/2021
Risk and issue  The process of risk management that includes identifying, analyzing and addressing risks in
management order to mitigate their negative effects on a project.
approach
Issue priority  The importance of the issue severity, ranked low, medium or high.
Risk response  The process of developing strategic options, and determining actions, to reduce threats to the
strategy project's objectives. Risk response strategies can include: (1) accept (2) avoid (3) mitigate and
(4) transfer.
Risk probability  The likelihood (chance) of the risk actually occurring.
Risk impact  Assesses the impact on the program should the risk be realized.
Risk timeframe  Defines when risk is most likely to occur and is used to determine when the risk management
activities must begin.
Risk register  A critical document that contains information about identified risks, issues, analysis and
evaluations of risks severity, the probability and the possible mitigation options.
Risk statement  Approach to distinguish the risk from its cause(s) and effect(s), by utilizing a three-part
statement in the form: “As a result of [CAUSE], [RISK] may occur, which would lead to
[EFFECT].”

03/10/2021
7. Scope Management and Change Control Plan
7.1 Introduction
This section describes the process for handling changes to any One Washington project baseline, defined by the
approved scope, schedule, and cost (i.e., the “triple constraint”). The One Washington change control process is
defined for how the project will capture, evaluate and make decisions related to any requested changes.
A baseline is the approved version of a work product that can be changed only through formal change
control procedures.
One Washington includes the following program baselines:
 Scope: the approved scope document describes the products, services, and results to be provided by the
One Washington program
 Schedule: the master project plan is the representation of the plan for executing all One Washington
program releases and activities, including durations, dependencies, and milestones
 Budget: the current approved One Washington technology budget, as well as the Cost Management
section of this Playbook, outlines the One Washington spend plan for authorized expenditures and cost
allocations
A change to any one of the above baselined components may necessitate a change to the others. The change
control process, therefore, must include an assessment of all three baseline planning artifacts. This assessment is
conducted as a part of the impact analysis completed once a change request (CR) is received by the One
Washington PMO. In addition, other dependencies and impacts should always be considered during this
assessment of a submitted CR.
The purpose of this document is to define the One Washington standard process for:
 Defining the change control roles and responsibilities

 Capturing and documenting CRs
 Conducting impact analysis to resolve CR uncertainties
 The One Washington PMO will facilitate effective CR decision-making at the appropriate level of
governance
 Updating and reporting the status of the CR
 Describing the tools, including change request form and change log
7.2 Change Control Roles and Responsibilities

The table below outlines the roles and responsibilities for the change request process. Please note that
responsibilities can vary, depending upon the CR and level of governance required to make the proper CR
decision, a process that will be managed and controlled by the One Washington PMO.

03/10/2021
Table 28. Change Control Roles and Responsibilities
Executive Sponsor  Provides approval or rejection of all escalated CRs from the ESC
Executive Steering  Reviews CRs and validates viability, estimates, and evaluations
Committee (ESC)
 Works with PMO to determine whether CR should be approved, deferred,
rejected, or escalated to Executive Sponsor
Business Transformation  Reviews CRs and validates viability, estimates, and evaluations
Board (BTB)
rejected, or escalated to ESC; and if so, provides CR recommendation
Advisory Committees  Review CRs and determine viability
 Provide SMEs to perform impact analysis of the CR in collaboration with the
PMO
 Verify and validate business requirements, perform estimation, including size,
schedule, and cost (in term of labor and other resources), and provide
recommendations
rejected, or escalated to BTB; and if so, provides CR recommendation
Project Management  Reviews CRs and determines viability, estimates, and evaluations
Office (PMO)
 Determines if CR should be approved, deferred, rejected, or whether CR
needs to be escalated
 Coordinates CR decisions and oversees the analysis, facilitating coordination
of additional resources as needed to complete the CR
 Reviews all open CRs, updates status, facilitates the approval process, and
ensures that CRs are documented properly in the CR log
 Determines how the approved changes have impacted the baselines (re-
baselining is generally done after a major gate, budgeting or other major
program event)
 Coordinates or manages the completion of action items necessary to
incorporate changes into the program, including monitoring the approved CRs
activities and reporting status until all work to implement the change is
completed
 Coordinates with other stakeholders, as necessary
Vendors  For vendor-initiated CRs:
 Develop justification for change and perform impact analysis of the CR
 Complete estimations, including size, schedule and cost (in terms of labor and
other resources)
 Confirms requirement verifications
 Reviews CR proposal and provide recommendation to contract manager (refer
to Vendor Management Plan )

03/10/2021
Stakeholders  As assigned:
 Work collaboratively to validate CR requirements
 Verify business requirements associated with CR
 Perform impact analysis of the CR, including assistance in development of
impact analysis and CR overview
 Develop justification for change
 Perform estimation, including size, schedule and cost (in terms of labor and
other resources)
 Recommend CR decision (i.e., approve, reject or defer) with rationale details
7.3 Change Control Guiding Principles

This section defines important guiding principles driving the One Washington change control process:
 Any change to an approved scope, schedule, or budget baseline requires a change request (CR). The
PMO encourages that all change requests go through this process, even if they have zero or minimal
impact to scope, schedule, or budget. This provides transparency and helps facilitate communication.
Changes are normal part of project delivery.
 The One Washington PMO will handle all logistics and tracking of CRs, including the change request form
and change control log. All CRs, their status and any associated documentation will be maintained by the
PMO in the Change Request Log on SharePoint: Change Request Log
 All CRs will be assessed by the PMO to determine the appropriate authorities to approve the request.
The approach is to enable decision-making on CRs at the lowest level possible, while recognizing that a
CR may need to be escalated to the ESC for final decision.
 An approved change request that impacts the work of any contractor may result in an amendment to a
contract. The contract amendment process is described in the Vendor Management Plan.
 Amendments to contracts usually result in impacts to the budget and it is therefore critical that contract
managers follow both the change management processes outlined in this section of the Playbook, as
well as the processes outlined in the vendor management plan.
 

03/10/2021
7.4 Change Control Process

This section describes the activities for creating, evaluating and approving CRs. The workflow for the change
control process is shown below:
Figure 21. One Washington Change Control Process
7.4.1 Create a new CR

The need for a change request can be identified by One Washington workstream team leads, working with the
PMO and using the One Washington project change request form. The originator is the requesting party and will
need to provide the date that the request is submitted, a description of the change, the reason for the change,
date required, and any other pertinent information that they may have concerning the change.
The change request form is located on SharePoint under:
 Documents >
 Project Management Plans >
 Change Management Plan folder > Change Request Form

03/10/2021
The status of the CR defaults to ‘new’ when created and is recorded in the change request log. The change
request log is managed by the PMO on SharePoint:
 Documents >
 Change Management Plan folder > Change Request Log
7.4.2 Prepare CR Overview and Impact Analysis

Once the CR is requested, the PMO manager assigns the CR to the appropriate One Washington team member
for analysis and due diligence. The assigned team member, in consultation with SMEs, stakeholders and other
team members, will complete the overview and impact summary portions of the CR form in preparation for the
formal review by the appropriate governance body. The specific individuals or workgroup involved in this
analysis is situation dependent and will vary on a case-by-case basis.
The assigned team member, with assistance as described above, will proceed with completing an impact
analysis, to include schedule and cost estimation impacts. Along with the impact analysis, the individuals will
determine what any high-level actions needed to incorporate the change into the program. This may include
changes to the schedule, budget documents, contract amendments, charter, resource lists, etc.
The PMO will update the status of the CR to ‘prepared’ in the change log when the CR is ready to proceed to step
7.4.3. Perform initial CR review.
A CR that has been deferred and reached its re-review date reenters the process starting at this step.
7.4.3 Perform Initial CR Review

The PMO sends the CR with the impact analysis to the appropriate governance body for an initial review; the
governance body will review the impact analysis and make a decision regarding how to proceed.
During the initial review of the CR, the governance body will determine whether the CR is valid and determine
whether the CR needs to be escalated to the ESC and/or the executive sponsor.
If determined not to be valid, the status is updated to ‘rejected’ and the reason for rejection is documented on
the form (step 7.4.5. Record change request outcome and communicate results) and the CR status is ‘closed’
within the change log.
CRs requiring additional information and/or analysis following the initial development of the CR impact analysis
and overview will be re-routed back to the previous step for more refined CR analysis and/or impact analysis.

03/10/2021
7.4.4 Make CR Decision

After performing the initial review, any adjustments and/or refinements to a valid CR will be completed and the
assigned governance body will review the revised CR and make a decision, or escalate to the next governance
body for a final decision. This step includes the process for preparing for the CR decision meeting, which will be
supported by the PMO.
7.4.5 Record and Communicate CR Outcome

The possible decisions for a CR are shown in the table below:
Table 29. Record and Communicate CR Outcome
Decision Action
Deferred  For valid changes, the reviewing governance body first determines whether or not
to defer the decision on the CR. If they determine it should be deferred, the PMO
will perform the following:
o Update the status to ‘deferred’ within the change log
o Document the date for which the PMO will reconsider the CR and describe
the reason for the deferral is documented on the form.
 The governance body formalizes the decision. The CR is then sent back to Step 2 of
the CR process: Prepare CR Overview and Impact Analysis; when the deferral date is
reached, the CR owner updates the CR with current information in preparation for
PMO review
Escalated  If the CR is escalated by the reviewing governance body, it will be sent back to Step
2 to prepare the CR for the next escalation governance body review, and the PMO
will determine how to proceed
 The PMO sets the CR status to ‘reviewed by’ in the change log and completes the
process by communicating the results to the change requester
Accepted  The CR is approved by the reviewing governance body and the PMO will develop a
recommended action plan to implement the CR
 The PMO sets the CR status to ‘approved’ in the change log and it then goes to Step
6: Create Action Plan to Implement Approved Change
Rejected  The CR is rejected by the reviewing governance body, and they formalize the
decision through proper documentation
 The PMO sets the CR status to ‘rejected’ in the change log and completes the
process by communicating the results to the change requester
If the requesting party disagrees with a CR decision, they may appeal the decision or create a new CR that
provides more information in support of the requested change.

03/10/2021
7.4.6 Create Action Plan to Implement Change

The PMO requires the development of an action plan to implement the approved change, which will require an
additional review and approval.
For approved CRs, the PMO will coordinate the completion of all necessary action items to incorporate the
approved changes into the program. These action items may include modifications to the program schedule,
budget, and/or charter and could include amending vendor contracts. Upon approval of the CR action plan by
the PMO, the change control process will conclude.
7.5 One Washington Change Log

The change request log will be monitored and tracked by the One Washington PMO and contains the following
fields:
 ID
 Date Logged
 Status
 Originator
 Date Submitted
 Change Description
 Reason for Change
 Date Required
 Summary of Impacts
 Approval Authority (Governance Level Required)
 Decision
 Date of Decision
 Notes
The change request log is located on the One Washington SharePoint:
 Documents >
 Change Management Plan > Change Control Log

03/10/2021
7.5.1 CR Statuses in the Change Log

The status of a CR may be one of the following as shown in the table below:
Table 30. CR Statuses in the Change Log
Decision Action
New  A new CR has been opened and is currently under review
Prepared  A CR that has been prepared for the initial review
Reviewed by  A CR that has been through the initial governance review, and was not
rejected or deferred
Analyzed  A CR that has been analyzed for potential changes to scope, schedule, staffing,
costs, quality and/or risks awaiting review and decision by the reviewing
governance party
Escalated  A CR that has been escalated to the next governance tier for action
Deferred  A CR has been deferred to a future time by the reviewing

governance body as documented in the change log
Approved  A CR that has been approved by the reviewing governance body
Rejected  A CR that has been rejected by the reviewing governance body
7.6 Change Control Monitoring and Meetings

The One Washington PMO will determine when CR meetings are needed, based on the quantity and/or impact
of open CRs. When a CR meeting is needed, the PMO will determine what project stakeholders and Governance
members need to attend; then send the invites and produce the meeting.
The PMO Manager, in conjunction with the project manager and appropriate Team Lead(s) will determine the
status of scope (i.e., red, yellow, or green) in weekly project status reports, based on the quantity and impact of
the open CRs in the Change Control Log, as part of weekly status report preparation and analysis. When the
total open and approved CRs amount to more than 5% of the baseline scope, scope status will typically be in
yellow status, and possibly red when it surpasses 7.5% and/or starts impacting schedule milestones and the
critical path.

03/10/2021
8. Requirements Management Plan
8.1 Requirements Management Overview

This section describes the processes that will be used on the One Washington project to prioritize, confirm,
develop and manage the Workday solution requirements throughout the life of the project. Requirements
management activities include working with key State business owners and stakeholders to review, analyze,
validate, and prioritize the functional and technical requirements, as defined by One Washington in the <SaaS
ERP SI – Requirements.xlsx> file created for this project.
As One Washington SaaS requirements are reviewed, validated and prioritized, they will be mapped to the
solution during Process Design and Discovery workshops conducted with the appropriate SMEs and business
owners in order to define User Personas and Moments that Matter for the end-users of the new solution. New
requirements may also be identified and documented that cover the “out-of-the-box” functionality that One
Washington Workday solution end-users will enjoy as part of the Workday transformation.
As these design elements evolve into One Washington Process Maps and User Stories, the confirmed and
prioritized One Washington requirements will all be traced and referenced to appropriate User Stories,
establishing the traceability relationship that will continue throughout the rest of the project until the solution is
implemented.
The traceability relationships will remain important references for the deployed system during the Sustainment
Phase, allowing the support team to understand the scope and impact of any changes to the production solution
by tracing them through their associated test scenarios/cases to their respective User Story(ies) and
requirements.
The figure below summarizes the Workday Momentum lifecycle that will be used to design, configure, test, and
deploy the One Washington solution:

03/10/2021
Figure 22. One Washington Design and Development Process
8.2 Requirements Management Roles and Responsibilities

The table below defines the roles and responsibilities for key players in the Process Design and Discovery (PDD)
workshops that will be executed for the One Washington project during the Imagine Phase of the project:
Table 31. Requirements Management Roles and Responsibilities
Facilitator  Coordinates meeting setup / prep
 Presents material during PDD workshops
 Orchestrates PDD workshops
 Engages One Washington SMEs to get their inputs and buy-in
Co-facilitator  Supports presentation technology (monitors, presentation software, demos, white
boards, easels, etc.) during PDD workshops
 Captures white board/easel contents digitally (taking pictures) at the end of each PDD
workshop
Scribe  Documents meeting minutes
 Documents proposed requirement edits, priorities, and clarifications
 Documents action items
 Documents parking lot items
 Documents risks, issues, assumptions, decisions, and change requests that occur
during PDD workshops
 Monitors PDD working session timing and agendas to keep workshops on track

03/10/2021
State  Identifies participants for PDD workshop prep, production and follow-up
Workstream  Oversees content development needed for PDD workshops and reviews
Leads
Deloitte  Confirms and manages scope of PDD workshops

Workstream  Supports the project vision and direction during the PDD workshops
Lead  Monitors PDD workshop progress and obstacles
 Drives meetings with project leadership to discuss risks, issues and items that may
need change control escalation
 Ultimately responsible for the completeness, accuracy and effectiveness of the
Requirements Traceability Matrix and links to Personas, Moments that Matter and
Process Maps
Business  Organizes PDD workshops and manages logistics for PDD Prep, PDD workshops and
Analyst reviews
 Maintains PDD workshop schedule, confirmed requirements and PDD outcome
documentation
 Documents and updates content for PDD workshops (e.g., meeting minutes, action
items, parking lot, and decisions)
One  Provide subject matter expertise during the One Washington Discovery and Design
Washington working sessions and reviews
SMEs and  Provide guidance on state of Washington standard operating policies, procedures, and
compliance items
Business
 Provide direction on One Washington vision, objectives, and priorities
Owners
8.3 Requirements Traceability Approach

Traceability links enable the ability to follow a requirement both forward and backward, from origin through
solution implementation. In order to establish robust traceability, each requirement must be uniquely and
persistently labeled so that it can be specifically tracked throughout the project.
The purpose of establishing traceability is to help:
 Understand the source of requirements

 Manage the scope of the project
 Manage changes to requirements
 Assess the project impact of a change in a requirement
 Assess the impact of a failure of a test on requirements (i.e., test failure may mean the requirement is
not satisfied)
 Verify that all system requirements are fulfilled by the implementation
 Verify that the application does only what it was intended to do
8.3.1 Requirements Traceability Elements

Requirements traceability elements provide an understanding of traceability relationships. A traceability link
between two elements indicates a dependency between them. The requirements relationships must be defined
first in order to design the project’s Requirements Traceability Matrix properly.

03/10/2021
The figure below illustrates the Requirements Traceability Elements and their corresponding relationships for the
One Washington project:
Figure 23. One Washington Requirements Traceability Elements
8.3.2 Requirements Traceability Matrix

The Requirements Traceability Matrix (RTM) for One Washington will be a stand-alone Excel workbook that
establishes, manages and maintains proper links between One Washington Workday solution Requirements,
User Stories, Configuration Workbooks, Integration Designs, and Test Scenarios (i.e., test cases and test
conditions) throughout the project lifecycle. The tool maintaining requirements to User Stories and facilitating
test management will be ALM Octane. Please see Section 12 Project Tools Strategy Plan for more information.
8.3.3 Requirements Traceability Maintenance

The One Washington Deloitte development team is defining a <One Washington Workday Configuration and
Naming Standards.docx> document that will be strictly followed and maintained throughout the project in order
to identify and track Workstream design and configuration components consistently and accurately. Great care
will also be taken to help ensure that requirements bi-directional traceability links remain intact and accurate in
design deliverables and work products throughout the Imagine and Deliver activities of the One Washington
project, and the stand-alone RTM connecting RequirementsUser StoriesConfiguration
WorkbooksIntegration Designs Test Cases is up-to-date, accurate, and maintained.

03/10/2021
9. Development Management Plan
9.1 Development Management Overview

This section describes the standard approaches that will be used to design, configure and convert, test, and
integrate the components comprising the One Washington Workday solution. Standards help ensure that
development and configurations adhere to guidelines intended in order to promote good development practices
and minimize the work required for future software upgrades.
The ownership of specific development areas will be shared by the State and Deloitte. Deloitte will be the
primary owner for the majority of the project scope. See sections 4.3 Responsibility Matrix: Configuration
Components and Design Updates, 7.2 Responsibility Matrix: Integration and Interface, 8.2. Responsibility Matrix:
Data Conversion, and 9.5.Responsibility Matrix: Reports, Dashboards and BIRT Development in the Statement of
Work.
Guidelines that will be followed as One Washington user stories are defined, configured, tested and integrated
into the Workday solution are listed below:
 Confirm that all solution functional and technical requirements are properly documented and prioritized:
the prioritization and ranking of user stories early in the process will be a key success factor
 Estimate the user story size (in story points) and implementation effort (in hours)
 Document acceptance criteria (definition of done) for each user story
 Update user stories as more information becomes available to accurately reflect the functional and
technical requirements for the project
 Prioritize and sequence user stories; priorities may be adjusted as new information becomes available,
or new user stories emerge from configuration reviews
 Once prioritized, allocate user stories into appropriate configuration cycles
 Perform proper change control, as defined in Section 7 of the Project Management Playbook
9.2 Development Management Roles and Responsibilities

Below is an overview of the roles and responsibilities of the team members that will be involved in the One
Washington Workday solution.
Table 32. Development Management Roles and Responsibilities
Integration Lead  Oversee the Workday integration process and confirm timely, incremental
deliveries
 Responsible for the design, build, and unit testing of the interfaces connecting the
One Washington Workday solution
 Communicate timeline and dependencies with the system owners and functional
team
 Work with the Technical Architect Lead and Security Lead to design and deliver
an effective, secure solution
 Manage the Workday software builds and integration management processes
 Plan and manage the various test cycles, code migrations, and deployment
milestones defined in the project schedule

03/10/2021
Workstream  Direct design/configuration review meetings
Leads  Manage the Workday configuration development staff who interact with the quality
and testing teams; manage the Workday solution build and configuration
management processes
 Provide weekly status of development activities and accomplishments to the PMO
 Validate key activities such as code review, requirements traceability and unit
testing
 Validate that the configuration team adhered to configuration standards
 Lead the development and functional teams to meet delivery dates, tracking
progress against the project schedule
 Analyze the business requirements provided by the application team to confirm
functional requirements
 Assist the reporting team in identifying report specifications and the configuration
of setup data required for report development and testing
Configuration  Provide estimates for configuration of features and functionality
Team  Configure and unit test Workday objects
 Adhere to design and configuration standards
 Conduct peer reviews
 Participate in design/configuration review meetings
 Establish configuration in Workday that will enable interfaces to work as expected
 Maintain source code
 Coordinate activities with other developers in preparing the task list for Check
Point/Quality Builds
 Analyze/correct defects discovered during testing of the solution
 Define and maintain traceability of detailed application design and configuration
artifacts
 Define/maintain the solution detailed application design artifacts
State SMEs and  Provide and confirm integration design requirements
Business Owners  Assist with setup configuration and connectivity from the external systems which
will be integrated with Informatica/Workday
 Ensure that the data is in the correct format, as defined in the functional
specifications
 Ensure the proper availability of resources and systems during the various test
phases
 Confirm requirements of the reports in the Imagine phase, and test them during
the Deliver phase
 Contribute to sprint planning and execution for report development
 Test and confirm reports for production readiness

03/10/2021
9.3 Solution Development Approach

The figure below illustrates the high-level approach that will be used to configure and confirm the One
Washington Workday solution:
Figure 24. One Washington Configuration and Confirmation Process
Specific planning for 1A configuration, data conversion and integration work will begin once the brunt of the
Discovery and Design session work is complete and the primary Workday 1A User Stories are defined.
9.3.1 Workday Solution Security

A key component to the One Washington Workday solution will be the security design and architecture that will
be developed to protect the application and its data. Per the SOW, the Deloitte team will configure
authentication and authorization functionality for the One Washington Workday solution to comply with Data
Confidentiality, Encryption, Privacy and Audit requirements as defined in the Schedule E (ERP Security Matrix) of
the Umbrella Terms and Conditions contract between Deloitte and the State. The testing team will plan and
execute appropriate security testing cycles to validate that the Workday solution configuration is secure and
sufficiently protected.
The technical team will define the authentication approach in the Solution Architecture deliverable and work
with the State to build and configure the appropriate identity and access management components that the
Workday solution will use for user access authentication.
Workday role-based security definitions will be created during Process Design and Discovery sessions, with
validation occurring during customer confirmation sessions, as well as in the testing phase. During integration
design, the security requirements will be identified and documented in the Integration Design deliverable.
Deloitte will support the State in defining and configuring security for the integrations being implemented by the
State.

03/10/2021
Workday Mobile is in scope for the Workday solution and the following functionality authentication options will
be reviewed and considered during solution design. Deloitte will work the appropriate State project team
members to define, configure and validate the right Workday mobile options for the State. The Mobile
implementation configuration will be documented as a project decision:
 Establishing up to three (3) tenant aliases

 Mobile PIN
 One-Time Passcode
 Workday Mobile delivered Push Notifications and Workday Drive, a file storage location provided by
Workday, secured by Workday security mechanisms
 Workday Mobile delivered Employee Self-Service and Manager Self-Service functionality associated with
in scope capabilities as referenced in Workday’s ‘List Tasks Available on Mobile’ report
 Enable Single Sign-on (SSO) authentication and MFA, including up to five (5) mobile-specific rulesets
 Up to three (3) intersection security groups specific to mobile. An intersection security group comprises
one or more security groups and includes users who are in all of the groups. Example uses of intersection
security groups include restricting access to workers in sensitive positions.
9.3.1.1 Workday Solution Security Responsibility Summary
The table below summarizes the primary and support responsibilities between Deloitte and the State regarding
the One Washington Workday solution security features and functions, from design and architecture to
validation and testing:
Table 33. Workday Solution Security Responsibility Summary
One
Deloitte
Activity Milestone/Deliverable Washington
Responsibility
Responsibility
Complete Workday Deliverable: Project Team Workday Training Support Primary
Security training Plan and Training
Create Solution Deliverable: Solution Architecture Primary Support
Architecture
Create and define Deliverable: Configuration Security Primary Support
Configuration Security Framework
Framework
Develop mobile usage Deliverable: Mobile Usage Deployment Primary Support
deployment Requirements
requirements
Conduct authentication N/A Primary Support
design sessions
Update SAW N/A Support Primary
authentication
components as required
to support the Workday
implementation

03/10/2021
One
Deloitte
Activity Milestone/Deliverable Washington
Responsibility
Responsibility
Configure authentication Milestone: Configuration 1 Tenant Build Primary Support
process in Workday
tenant
Test authorization Milestone: Configuration 1 Tenant Build Primary Support
authentication process in
Workday tenant
Conduct Discovery and Deliverable: Configuration Security Primary Support
Design Sessions Framework
Conduct Integration Deliverable: Integration Design Primary Support
Design Sessions
Conduct Integration Deliverable: Integration Design – State Support Primary
Design Sessions – State
Configure role-based Milestone: Configuration 1 Tenant Build Primary Support
security and unit test
Review roles-based Milestone: Customer Confirmation Sessions Primary Support
security
Test role-based security Deliverable: End-to-End Test Results Support Primary
Configure integration Deliverable: Integrations Developed and Unit Primary Support

security and unit test - Test - Contractor
Contractor
Configure integration Deliverable: Integrations Developed and Unit Support Primary
security and unit test – Test - State
State with support from
Contractor
Test Integration security Deliverable: End-to-End Test Results Support Primary

03/10/2021
9.3.2 Workday Data Conversion Approach

The illustration below summarizes the overall sequential approach that will be used to plan, execute and deliver
the data conversions required for the One Washington Workday solution:
Figure 25. One Washington Data Conversion Process
9.3.3 Integration Development

The Deloitte technical team will use Workday technical specifications to write the application code for the
integration interfaces needed for the One Washington Workday solution. In addition, depending on the technical
requirements for each interface, the integration work may require the creation of additional code artifacts or
test data sets in order to properly unit test interfaces and simulate external partner integrations.
The figure below illustrates the high-level framework that will be used to plan, execute and deliver the solution
integration work required for the One Washington Workday solution:
Figure 26. One Washington Workday Solution Integration Framework

03/10/2021
9.3.4 Reporting Development

The illustration below summarizes the high-level approach that will be used to plan the reporting components
required by the State as part of the One Washington Workday solution:
Figure 27. One Washington Workday Solution Reporting Approach

03/10/2021
10. Document Management Plan
10.1 Document Management Overview and PMO Responsibilities

This section describes how One Washington project documents will be named, stored, managed and archived.
The owner of the OFM-Teams-OneWa-Program Team SharePoint site is Ms. Liz Hoxit (liz.hoxit@ofm.wa.gov).
The PMO will work with Liz to perform the following regarding the care and handling of One Washington project
documents:
 Establish and maintain the project Document Management Plan (i.e., this section) of the Project
Management Playbook
 Establish and manage the One Washington SharePoint project document management system
 Manage, maintain, and control project documents on the SharePoint site
 Work with the PMO to update any baselined documents under change control that need to change as a
result of an approved Change Request (CR)
o Please see Section 7 for more details about the One Washington Change Control process
10.2 Document Management Tool

As mentioned above, the document management system for the One Washington project is Microsoft
SharePoint. This tool will be administered by Liz Hoxit and accessible by all qualifying project team members.
The SharePoint document repository will retain version history of all documents automatically for archival
purposes and version control.
10.3 Document Management Directory Structure

The One Washington project SharePoint tool contains team sites and several libraries, with access dependent
upon the OFM-Teams-OneWa Program Team SharePoint site user group a person is assigned to for read and/or
write access. The SharePoint tool is continuously evolving – the current team sites available include the
following: Program Team Home; PMO; Communications; Finance Team; OCM (Organizational Change
Management); Technology Team; and Program Archive – please see the sample screenshot below:
Figure 28. One Washington Program SharePoint Home Page

03/10/2021
Additional team sites (e.g., Business Operations and Technical Team) are in development, and new libraries and
folders will be defined and created as needed to support the document management needs of the project. The
One Washington SharePoint Architecture Framework can be found at this Link - One Washington Program
SharePoint Architecture.
10.3.1 Controlled Library for Approved (and Baselined) Project Deliverables

In addition to the SharePoint team sites and folders described above, there is a restricted library in the OFM-
Teams-OneWa-Program Team SharePoint tool that will be strictly used to archive approved, baselined project
deliverable documents, thereby putting them under change control (i.e., “controlled documents”).
The library is called Approved Deliverables and will house both approved Deliverable Expectation Documents
(DEDs) and deliverable documents. One Washington project leadership and team leads will have read-only
access to this library, but only a small group of team members managing change control for the project will have
write/delete access in this Library. This select group currently includes the following five (5) individuals:
1. Matthew Toney: Project Manager – Operations

2. Liz Hoxit: SharePoint Administrator/Management Analyst
3. Trish Almond: Business Operations Manager
4. John Cook: PMO Co-manager
5. Liz Colón: PMO Co-manager
Please see Section 16.3 in this Project Management Playbook for more information regarding the project change
control process.
10.3.2 Microsoft Teams Site

The OFM-Teams-OneWa-Program Team SharePoint site also offers a link to the One Washington Microsoft
Teams site. Microsoft Teams is a newer chat-based workspace app that facilitates ongoing collaboration and
communication among team members. It also provides single-point access to conversations, files, notes, and
tasks.
The Microsoft Teams site for the One Washington project is a less formal working space, and thus is more
flexible and dynamic in terms of defining folders and how to share and collaborate on working documents.
10.4 Document Management Process

This section describes how managed documents (i.e., work products, draft and WIP deliverables) and controlled
documents (i.e., approved, baselined deliverable documents) will be stored, managed and controlled.
10.4.1 Work Products and Deliverables in Development
10.4.1.1 Document Development in Microsoft Teams

Documents in initial development can be managed by individual team members under the guidance of their
respective team leads. During initial development within a particular team, team members can use Microsoft
Teams to collaborate and work together on work-in-progress (WIP) documents in Microsoft Teams.

03/10/2021
Please note: It is One Washington policy to NOT use the OneDrive feature in Microsoft Teams to share and
collaborate with other team members on documents. Place working documents in Microsoft Teams folders for
team collaboration and development purposes.
10.4.1.2 Document Development in Microsoft SharePoint

Once a WIP document, whether it be a work product or a deliverable, needs to have reviewers outside the team
review the document and provide edits and/or comments, the document must be posted in an appropriate
folder on the OFM-OneWa Program Team SharePoint site, and follow conventional SharePoint Check-in/Check-
out protocols in order to capture all updates and manage document versioning more formally.
10.4.2 Approved Deliverables Placed Under Change Control

As project deliverables go through the formal review and approval process with the State, approved deliverable
documents will be baselined and archived in the designated controlled Approved Deliverables library in the
OFM-OneWa Program Team SharePoint, managed and controlled by the PMO. The PMO will manage the formal
deliverable review and sign-off procedures and archive documents that comprise an approved deliverable.
Once an approved deliverable document is archived in the Approved Deliverables library, it cannot be updated
or edited without an approved change request (please see Section 7) – it is under change control.
Team leads may also want to post/publish/share final versions of work products (i.e., documents that are NOT
deliverables requiring formal sign-off) with the PMO, so that those documents can also be archived in
appropriate Final Work Products folders separate from the controlled Approved Deliverables library for record-
keeping. These final work product documents are NOT under change control and can be updated without an
approved CR, but best practices require that the Document/Version Control section in the front of every project
work product document be kept up-to-date with any document revision or updates.
Please see Section 14.6.2 Deliverable Management Process of the Quality Management Plan in this Playbook for
more information regarding the standard One Washington project deliverable management process.
10.5 Document Naming Standards

10.5.1 Formal Project Deliverable and Work Product Documents on SharePoint
The table below describes the document naming conventions to be followed for the One Washington project for
DEDs and their corresponding deliverable (DELs) documents, as well as any work product documents that need
to be posted and managed on the OFM-Teams-OneWa-Program Team SharePoint site.
The DED and DEL number (“###”) must correspond to the number of the deliverable designated in the One
Washington project Deliverables Log (i.e., <OneWa-005DEL-Deliverables Log.xlsx>).
Please Note: Software file naming conventions are addressed and maintained in the <One Washington Workday
Configuration and Naming Standards.docx> document.

03/10/2021
Table 34. Document Naming Standards
Managed and Controlled Documents File-naming Standards
# Description Naming Convention

1 DED documents <OneWa-###DED-DED Name>.<File Extension>
Example: OneWa-003DED-Project Management Playbook.docx
2 Project deliverable <OneWa-###DEL-Deliverable Name>.<File Extension>

documents
Example: OneWa-001DEL-Project Kick-off Session.pptx
3 Project work product <OneWa-Work Product Name>.<File Extension>

documents
Example: OneWa-Finance Team Goals.xlsx
Note: As a general rule, all One Washington deliverables and work product documents should NOT contain a
version number or date in their filename: those details will be maintained in the Version Control table at the
front of every document, as well as the versioning and tracking capabilities provided by SharePoint.
10.5.2 Informal Working Documents and Reference Materials on Microsoft Teams

Working and reference documents that project teams share and collaborate on in Microsoft Teams do NOT have
to follow the file-naming standards presented in the section above, but it is recommended that they follow the
work product document naming standards: i.e., <OneWa-Document Name>.<File Extension>
10.5.3 Document Naming Standards for All One Washington Project Documents
Regardless of whether the document is a team working document posted in Microsoft Teams, or a deliverable
being prepared for formal review and approval in the SharePoint site, the following Do’s and Don’ts apply to ALL
One Washington project documents:
Do’s
 Create libraries vs folders

 Use metadata to tag documents
Don’ts
 Name files with a version number

 Name files beginning or ending with a space
 Name files beginning or ending with a period
 Name files that contain unsupported Unicode characters
 Name files that contain the following characters " * : < > ? / \ |
 Store certain types of files (ISO, EXE, BAT, etc.)
 Use duplicate filenames
 Use OneDrive files for collaboration – use SharePoint or Teams

03/10/2021
10.6 Document Management Tool Administration

This section describes how the One Washington SharePoint site will be configured and managed to provide
proper access, backup and recovery, and archiving of project documents throughout the life of the project, and
beyond (End-of-Project Archives). For more information, please go to the One Washington File Storage Options
Site.
10.6.1 Team Member Access to SharePoint

All One Washington project team members needing access to the project SharePoint site need to contact
SharePoint owner Liz Hoxit (liz.hoxit@ofm.wa.gov).
10.6.2 Project Document Backup and Recovery

<Need One Washington SharePoint back-up and recovery high-level description here, including frequency info. –
Liz Hoxit working on what to provide here.>
10.6.3 End of Project Document Archives

<Need One Washington reference to policy(ies) regarding removal/deletion/archival of project documents at the
end of the One Washington project, to meet State and Deloitte record-keeping compliance rules and protocols –
Liz Hoxit is working on this...>

03/10/2021
11. Resource Management Plan
11.1 Resource Management Overview

This section of the Playbook addresses resource management for the One Washington program, from labor and
non-labor resource perspectives. The Labor Resource Plan includes the processes that organize, plan, acquire
and lead the program staff, vendors and in-kind resources to successfully achieve program goals and objectives.
11.1.1 Purpose and Scope

The purpose of this Resource Management Plan is to help to ensure complete and adequate labor and non-labor
resources are allocated and made available to the project.
From a labor perspective, it provides a staffing model, as well as plans and processes for managing and
controlling human resources and their activities within the One Washington program, including:
 The program’s organizational structure

 The roles and responsibilities of program members
 How staff will be acquired and trained
 How staff will be increased and reduced as appropriate
 How staff levels will be managed
This plan covers the management of staff within the One Washington program that will support the design,
development and implementation of the selected Workday solution. This process applies to OFM staff and state
supplemental staff (i.e., contracted staff and partner agency staff) only. This plan does not specifically address
the staff that agencies will require to integrate with the Workday solution. A high-level description of the
approach to managing non-program resources is provided in the resource management process section below.
This plan is considered a living document and will be updated periodically. Specific events that maytrigger
updates to this plan include:
 Review of the resource requirements by the ERP procurement assistance consultant, ERPexpert advisor
and system integrator (Deloitte)
 Finalization of maintenance and operations plans at each implementation stage
 Final funding approval at the end of each budget cycle
Other updates to the plan may be necessary throughout the program’s duration and will be made at thedirection
of either the business operations manager, PMO manager, program director or the executive director.
11.2 Labor Resource Plan

To support the activities of the One Washington program, a combination of OFM staff, in-kind agency resources
and contracted personnel will be utilized. While most of this staff will be assigned full-time to the project, some
resources may be allocated less than 100%. Each staff member will be assigned to a specific team within the
overall project organization.
The One Washington program includes four (4) core projects or workstreams for solution implementation:

03/10/2021
1. Finance
2. Procurement
3. Budget
4. HR and payroll
Each project is led by a dedicated business owner. The following program teams will support each of theproject
teams throughout the lifecycle of the program: project management office, business operations management,
organizational change management and technical management.
Please see Section 2 – Project Organization and Section 3 – Project Governance for details about the organization
of the implementation project team and the program governance structure and escalation procedures.
In addition, bluecrane has been contracted as the program’s quality assurance consultant, to provide
independent assessments of the health of the One Washington program, as required by OCIO Policy 132. The
program also benefits from having OCIO consultants assigned as oversight to the program. This oversight will
help to ensure the program stays on track and follows applicable external guidelines.
11.2.1 Program Roles and Responsibilities

The table below defines the key roles involved in the One Washington program, including their titles,
descriptions, and key responsibilities.
Table 35. Program Roles and Responsibilities
Title Role Key Responsibilities

Description
Executive Director This role provides leadership and guidance  Define program vision, goals
for the program. Acts as an “owner” and and objectives
champion of the program insupport of  Approve program budget and
meeting the executive changes
sponsor and executive steering

03/10/2021

Description
committee’s expectations. The executive  Approve program change
director has strategic and tactical plan requests to baseline (i.e.,
execution responsibility, which includes scope,resources and budget)
scope, schedule, budget and quality.  Communicate program goals,
objectives, and priorities
The executive director reports to the  Approve solution vendor
executive sponsor. contract
 Approve, review, monitor and
report program metrics
 Resolve issues that could notbe
resolved at lower levels
 Can perform duties as a
vendor contract manager
 Provide status updates and
progress reports to the
executive sponsor and executive
steering committee

03/10/2021
Description
Program Director This role directs program activities, provides  Accountable for overall
operational and tactical direction to the execution, management and
program teams to assist in identifying proper delivery of the program’s:
level/forum for where key decisions are scope, schedule, budget and
made, assists with alignment of resources, sustained operations
framing/boundaries for scope and adviceon  Provide leadership to program
project budget. functional team
leaders/managers
The program director reports to the  Approve and monitor all
executive director. program management plans
and processes
 Plan and manage program
activities
 Manage program schedule and
costs
 Track and report progress to
stakeholders
 Manage and resolve issues and
risks
 Provide status updates and
progress reports to business
transformation board
 Can act as vendor contract
manager
 Responsible for coordination
with the functional business
owners

03/10/2021

Description
Chief Technology This role is responsible for providing sound  Develop and execute the One
Officer (CTO) technical leadership in all aspectsof the One Washington technology
Washington program and providing architecture and strategy
technical leadership for the implementation  Ensure the technology
of the ERP solution. architecture and strategy are
compatible with the selected
The chief technology officer reports tothe ERP vendor’s technology
program director. platform and capabilities
 Articulate the technology
architecture and strategy to
agency IT executives
 Monitor the technical
implementation of the ERP
solution including oversight of
technical service level
agreements within the ERP
vendor contract
 Lead the implementation of
technical maintenance and
operations processes and
methodologies based on
industry best practices
 Participates in all IT advisory
committees
Technical Lead This role is responsible for providing sound  Single point of authority and
technical guidance in all aspects ofthe One technical responsibility for
Washington program and providing technical statewide ERP solution
leadership for the implementation of the ERP  Provide leadership, mentoring
solution. and leads technical teams in
executing project deliverables
The technical lead reports to the chief  Establish priorities for
technology officer. developers, configurators, or
testers based on business
owner priority and feedback
 Align ERP software
implementation with OFM IT
strategy
 Work with teams to implement
processes and technology that
support business value and
improve efficiencies across
business and technical functions

03/10/2021

Description
Senior IT Architect This role serves as the expert on all  Lead/manage solution design,
technical work streams throughout the development and
program. This role will analyze technical implementation for mission
processes, determine specifications and critical, high visibility systems
communicate needs clearly to program within the One Washington
leadership. This position will be responsible program and supporting other
for all aspects of the technical specifications state agencies
gathering activities as well as the technical  Ensure public-facing internet
aspectsof the system implementation applications follow established
including networking, cyber security, access, usability guidelines, architectural
identity management, cloud platform standards and security practices
delivery, high level approach to system  Develop new and innovative
integration and future state as well as enterprise level information
business continuity in the design. solutions in support of One
Washington
The senior IT architect reports to the  Develop conceptual and logical
chief technology officer.
artifacts so application
capabilities are aligned to
business outcomes
Data and Business This role leads the development of data  Develop overall data and
Intelligence governance and implementation strategyand business intelligence strategy
Manager execution for One Washington data and and framework
business intelligence solutions.  Facilitate the data governance
advisory committee to
The data and business intelligence manager establish One Washington’s
reports to the chief technologyofficer. data governance policies,
standards and procedures
 Develop One Washington data
models
 Collaborate with agency IT
staff to identify shared data,
develop data models and
adopt data standards

03/10/2021
Description
Business Analyst This role leads the development of data  Translates business
governance and implementation strategyand requirements into ERP
execution for One Washington data and solutions
business intelligence solutions.  Perform business systems and
workflow analysis, and
The business analyst reports to the chief disseminates technical
technology officer. communications
 Support and maintain related
ERP systems and processes to
meet business requirements
 Perform as subject matter expert
for ERP business relatedsystems

03/10/2021

Description
Organizational This role supports the mission of One  Provide organizational
Change Washington by leading and promoting the development and change
Management successful transformation of the state’s management leadership
Director employees, its stakeholders andtheir  Accountable for overall OCM
systems and processes, and the state’s communication strategy and
core business functions in preparation for plans
the implementation of new integrated  Support organizational change
systems. management communication
requirements
The organizational change management
 Participate in the developmentof
director reports to the executive director.
an organizational change
management plan
 Support creation and
distribution of quality
organizational development
and change management
materials
 Share change management
knowledge with business
functional professionals/IT
professionals, and provide
assistance in areas of
personnel expertise
 Facilitate the organizational
change management advisory
committee
 Acts as vendor contract
manager
Communications This role participates in the developmentof  Participate in the development

Consultant stakeholder assessments and and updates to the One
communications plans and executes those Washington communications plan
plans under the direction of the draft communications
organizational change management director.  Draft surveys and manages
survey data
The communications consultant reportsto  Maintain stakeholder lists
the OCM director.
 Maintain the program e-mail
box, website, and style guide,
etc.

03/10/2021

Description
Project Management This role manages the tactical activities ofthe  Accountable for execution of
Office Manager program, including the activities of the four tactical activities for the four
core projects (finance, procurement, budget core projects
and HR/payroll) and the activities of the  Ensure integrated program
PMO staff. schedule is maintained –
 provide regular reports
The project management office manager
 Manage the PMO staff activities
reports to the program director.
in support of the coreprojects
 Ensure core projects have an
assigned project manager
 Monitor, track and report
progress against scope, schedule
and budget including
identification and monitoring of
critical path
 Identify, analyze, prioritize,
manage and resolve issues and
risks
 Document and log decisions
 Ensure PMO process (scope,
schedule, resource quality, etc.)
are defined and followed
 Execute PMO process
 Ensure vendor contracts and
deliverables are appropriately
managed and reported
 Acts as vendor contract
manager

03/10/2021
Description
Project Managers These roles will support the transformation  Work with stakeholders and
of enterprise administrative/business business owners in defining
systems and implementation of information project scope, budget,
technology solutions by leading/managing schedules and deliverables
enterprise IT projectsand delivering results  Develop project work plans
using proven project management identifying all tasks necessaryto
methodology. complete project work streams
 Organize project work plans ina
The project manager positions report to the logical and efficient order
project management office manager.
 Conduct risk assessments and
identifies critical issues,
mitigation strategies and
escalates as appropriate
 Reprioritize and adjust work
plans for changing conditionsor
new information
 Develop reports on recurring
and ad-hoc basis
 Manage business areas and
technical activities

03/10/2021

Description
Project Coordinator This role is responsible for performing  Maintain project management
functions in support of project managers and processes and plans
will have specific duties and responsibilities  Maintain integrated project
assigned to them by the PMO manager. schedule
 Facilitate use of project
The project coordinator reports to the management processes in
PMO manager. support of project managers
 Facilitates vendor deliverable
review and approval processes
 Provide support to project
managers as needed
 Develop reports on either
reoccurring or ad-hoc basis
Business Functional These roles serve as One Washington's lead  Facilitate and lead the work and
Area Leads (Finance, subject matter experts on state enterprise stakeholder sessions with
Procurement, business process and systems (finance, business stakeholders to identify
Budget, HR and procurement, budget, HR and payroll); and document enterprise
Payroll) supporting the ongoing use and development business capabilities, business
of the state's new ERP system. Additionally, outcomes and user stories, to
they work to transform business operations understand and define business
and solve business problems by analyzing processes, policies and
business processes, determining business application specifications
needs and communicating clearly to  Produce project documentation
stakeholders, technology developers, and such as use cases, business
vendors. rules, functional requirements,
andnon-functional
The business functional leads report to the requirements
PMO manager.  Effectively translate business
problems and solutions to
technical staff
 Lead and support other staff on
the One Washington business
functional teams to meet
deliverables and understand tasks
and directionto ensure program
efforts are aligned with program
goals, and objectives are met
timely with quality work products
 Assist with future business line
training endeavors

03/10/2021

Description
Business Functional These roles provide subject matter  Facilitate and lead the work and
Area Subject Matter expertise and support across business stakeholder sessions with
Experts – functional aspects of their respective respective business stakeholders
Specialists business lines. They are involved in to identify and document
(Finance, activities such as business capabilities enterprise businesscapabilities,
Procurement, definition, use case and user story business outcomes and user
Budget, HR and development, business process analysisand stories, to understand and define
Payroll) redesign. business processes, policies and
application specifications for One
The business functional area subject matter Washington software selection
experts report to their respectivebusiness  Produce project documentation
functional lead. such as use cases, business
rules, functional requirements,
andnon-functional
requirements
 Effectively translate business
problems and solutions to
technical staff
 Perform tasks as assigned by
the project manager
 Manage day-to-day issues that
arise to ensure the right staff are
involved in appropriate tasks on a
timely basis
 Responsible for supporting the
project managers in the
execution and delivery of project
work products
 Provide initial review and
comment of vendor work
products and deliverables
 Responsible for producing
non-vendor specific work
products and getting review
and approval of those
products
 Assist in project documentation
management

03/10/2021

Description
Enterprise Senior This role supports the mission of One  Facilitate meetings to gather
Consultant Washington by running day-to-day status information, resolve
management of specific projects. issues, or facilitate team
Additionally, they will produce interaction
specific deliverables (such as  Implement change control
procedures and/orKPIs processes
methodologies) for monitoring  Communicate project changes
organizational performance and to project stakeholders
mediating issues with program or
 Perform risk assessment
enterprise-wide impact.
activities across subordinate
projects, including risk
The enterprise senior consultant reportsto
identification, mitigation,
the business operations manager.
status and tradeoff
recommendations that
balance strategic needs and
tactical actions
 Provides governance structure
and creates necessary
documents in support of
 Manage the coordination of
key stakeholder meetings
Business Operations This role is responsible for ensuring the  Manage program staffing and
Manager program’s core business functions are resources
performed including budget management,  Provide vendor contract
HR management, facilitiesmanagement and oversight for deliverables,
contracts management. Additionally, this management and creation
role provides team organizational  Establish business processes
development opportunities. and procedures (HR, budget,
contracts, facilities, etc.)
The business operations manager reports to
 Ensure business processes are
the executive director.
followed
 Report budget status, contract
status and any compliance issues
to program director/executive
director
 Report resource status including
hiring, termination,
performance, etc. to program
director/executive director

03/10/2021
Description
Budget Manager This role is responsible for creation of  Create budget documents in
budget documents, tracking expenditures, support of decision packages,
reporting status against budget and gated funding process and
representing the budget tostakeholders. investment plans
 Track program expenditures
The budget manager reports to the  Monitor and report actual and
business operations manager. projected spending vs. budget
 Prepare and revise the
technical budget
 Maintain internal budget
documentation
 Respond to budget questions from
external stakeholders (OCIO,
legislative staff, ESC, etc.)
Management This role supports the mission of One  Identify, recommend, and
Analyst Washington by serving as a consultant to implement ways to increase
executive management, leading the program operational
programs continuous process improvement efficiencies
efforts, and by providing operational support  Develop and/or report out on
to all levels of the program. fundamental business
operations
The management analyst reports to the  Plan, create, implement and
business operations manager. execute maintenance on
standardized tools and
business processes
 Develop executive-level
documents, program
presentations, meeting minutes,
agendas, memos, andstatus
reports
 Direct SharePoint
administration and
maintenance for a complex
multi-network SharePoint
environment

03/10/2021

Description
Executive Assistant This role serves as the program's  Manage calendar appointments
correspondence coordinator and is and schedulingfor the executive
responsible for managing incoming and director andprogram director
outgoing correspondence for the executive  Provide administrative supportto
director, which includes drafting, editing, executive director on legislative
and finalizing a varietyof executive-level matters, which includes managing
documents for signature. Additionally, the calendar, scheduling meetings,
executive assistant provides support to and monitoring emails
other program senior leaders.  Execute administrative
functions and assist with day-to-
The executive assistant reports to the day operations/functions
executive director.
 Assist with the logistics and
scheduling of stakeholder
meetings, workshops and
events
Business Owners These roles serve as the lead for the  Collaborates with OneWa and its
functional areas of finance, procurement, associated governing bodiesto
budget, HR and payroll. Business owners will identify business process areas
define and champion the implementation of for improvement
business process needs and requirements  Reports status to the program
related to theirrespective areas. This effort director and the business
will be in collaboration with program staff, transformation board
advisory committees and the business  Assess and decide software and
transformation board. system integrator that best fits
their functional areas
The business owners provide updates tothe
 Review and provide feedbackon
program director and do not report directly to
SI request for proposal
program staff.
 Communicate externally to
function constituencies –
business processes, benefits
 Assist in resolution of
resistance
 Collaborate with partner
agencies to implement
business process
improvements
 One Washington advocate
 Decides on the system design
direction for their functional
area
 Assist with future business line
training endeavors

03/10/2021
Additional responsibilities for many of these roles are specified in the Program and Technical RACI
referenced in Section 2.3 of this Playbook.
11.2.2 One Washington Program Staffing

To support the overall staffing needs, the program will recruit and hire State employees, as well as contract
with consultants to provide specific expertise. The program will also leverage in-kind resources through
interagency memorandums of understanding for additional project support. In general, State staff will serve
in leadership and management positions, where key-decisions need to be made and where knowledge must
be retained once the program is implemented.
Where specific technical knowledge is required, or where State resources are unavailable, the program will
rely on contracted consulting resources. Where vendors are responsible for the development, and
implementation of contracted deliverables, state and contracted staff will work with the vendors to develop
deliverables and transfer knowledge so that State staff have the skills needed to provide ongoing
maintenance and operations of the solution.
The following table identifies the staff that have been assigned to the One Washington program, by their
specific roles. It does NOT include the ERP (i.e., Workday) vendor staff responsible for the configuration and
implementation of the Workday solution. For a more detailed view of the overall staffing plan, please <
Resource Management and Staffing Plan>.
Table 36. State Resources
State Resources
Role Name
Executive Director Vann Smiley
Program Director Matthew Meacham
Executive Assistant Susanne McLemore
PMO Manager Lizzy Drown (OOO); PMO Co-Managers are John Cook and
Liz Colón
Project Manager - Operations Matthew Toney
Project Manager - Technical Charlene Bane
Project Coordinator Vacant
Subject Matter Expert – Finance Lead Mike Schaub
General Ledger Lead Steve Nielson
General Ledger SME Jayda Williams
Accounts Receivable Lead Laura Lopez
Asset Management Lead Keri Smith
Cost Allocation Lead Stacy Crawford
Grants Project Accounting SME Vacant
Subject Matter Expert – Finance Specialist Trinh Bui
Subject Matter Expert – Procurement Lead Vacant
Subject Matter Expert – Procurement Specialist Teri Lund
Chief Technology Officer Ann Bruner
Technical Lead Vacant
Version: 0.9 Page 135 of 169

03/10/2021
Senior IT Architect Mistyjean Brown
Data And Business Intelligence Manager Lori Jones
Communications Consultant Vacant
Business Operations Manager Trish Almond
Budget Manager Briana Samuela
Enterprise Senior Consultant Julie Thumser-Kerlee
Management Analyst Liz Hoxit
IT Contracts Lead* Becci Riley
IT Contracts/Procurement Specialist* Kristy Brodersen
Business Owner – Finance* Brian Tinney
Business Owner – Procurement* Jamie Rossmann
Business Owner – Budget* Nona Snell
Business Owner – HR/Payroll* Scott Nicholson
Contracted Resources
Role Name Company
Project Oversight Consultant Amy Pearson Office of the Chief
Information Officer
Project Consultant Stacy Steck Office of the Chief
Information Officer
Quality Assurance** Allen Mills and Jay Jackson bluecrane
Project Management, Project Coordination Dan Ward and Liz Colon Integrated Solutions Group
AndAdvisory Services**
Organizational Change Management Services** Jennifer Rocks and team Deloitte
ERP Procurement Assistance Consulting Robin Milne and team Plante Moran
Services**
ERP Expert Advisor** Thomas Ortiz Information Services Group
Benchmarking Services** N/A Hackett Group
Special Assistant Attorney General** Marc Lindsey and team LB3
Software Vendor TBD Workday
System Integrator** Fred Giacoma Deloitte
*In-kind resource via interagency agreement
**Conducted procurement process to obtain contracted resources
11.2.3 Resource Management Process

This section addresses: when and how human resource requirements will be acquired; the timeline for when
resources are needed and may be released; training for any resources with identified gaps in skills required;
and how performance reviews will be executed.
The program director, in consultation with the business operations manager, will be responsible for
identifying and assigning resources in accordance with the program’s organizational structure. All resources
must be approved by the executive director before the resource can begin any program work. The project
teams will likely be split between multiple locations, to include working remotely, and thus need flexibility in
terms of work location, facilities and space limitations.
03/10/2021
11.2.3.1 State Resource Acquisition
The One Washington PMO, with guidance from the executive director, program director, and business
operations manager, developed and maintains a staffing plan based on the requisite knowledge, skills and
experience needed for the positions required to support the program. Most of the program roles were
presented in the Roles and Responsibilities table shared in Section 11.2.1. Many of the positions require in-
depth knowledge of the state’s core business processes, as well as the systems that support those processes.
The program has and will continue to recruit for State staff with the requisite experience into program
positions. Additionally, based on program funding, these positions may change to better ensure project
completion.
Where appropriate, positions may be filled with contracted vendors that have the experience necessary to
fill the roles and responsibilities of the position. Contractors will be hired through a competitive
procurement process. The program director and business operations manager will define the requirements
for program resources, and the program must find resources with the requisite knowledge, skill, and
experience that can effectively perform their roles to achieve the goals and objectives of the program. The
program director and business operations manager will escalate any resource risks or issues to the executive
director, as needed.
11.2.3.2 Non-program Resources

The One Washington program will rely heavily on external resources to the program. This includes resources
from other State agencies that will participate in activities critical to the program’s success. In these
circumstances, the program will work with the agency to determine the level of effort and timeframe for the
assignments.
In addition to program staff and partner agency resources, the program has completed seven of eight
procurements to fill various vendor roles. Deloitte was chosen as the system integrator vendor and the 1A
release of the Workday implementation project that officially kicked off in January 2021.
11.2.3.3 Resource Onboarding and Offboarding

Throughout the life of the program, activities and staff qualifications will be reviewed to determine existing
skills, staffing levels and related gaps. As staff are hired, the program will take the necessary steps to
properly onboard new team members, as well as offboard resources leaving the program.
Resource Onboarding/Ramp-up
The One Washington program employs full-time State staff and contractors. This does not include the
executive sponsor, executive steering committee, business transformation board,or advisory committees.
The staffing table presented in Section 11.2.2 does not include additional staff that have been requested in
the program’s 2021-2023 decision package request. If that funding is approved, an update will be made to
this document highlighting new positions that will be part of the program.
Onboarding for positions included in the 2021 – 2023 decision package will begin in July 2021 and are
expected to occur in waves, based upon priority as determined by the program director and business

03/10/2021
operations manager. This Resource Management Plan section of the Playbook will be updated if resourcing
changes occur.
As the program evolves and implementation work begins, additional resources and/or modified roles may be
identified. When this occurs, first-line supervisors will be responsible for initiating a resource request to the
program director and business operations manager. This request will need to include an overview of how the
position will support the program’s overall mission, as well as the necessary skill sets and timeframes. The
program director and the business operations manager will be responsible for monitoring and prioritizing all
resource requests. Given the fluidity of staffing on projects of this size and the occasional need to ramp up
quickly, the State will strive to provide new contractors with laptops, badges, email, and other items
essential to their work within 10 business days of the initial request.
New resources that join the program will be provided a formal onboarding process, including project
orientation. The first-line supervisor (or contract manager for contractor resources) will be responsible for
delivering the project orientation. The orientation will include the following:
 OFM/One Washington policies and procedures

 Background and current status of the program
 Specific job duties and expectations
 Introduction to the staff and consultants
 Overview of the facility and infrastructure
 Overview of the project management plans and processes in place (i.e. schedule, vendor andquality
management plans, etc.)
Resource Offboarding/Ramp-down
As the program reaches key milestones and/or stages in the project, staff will need to be reduced or
transitioned to operational positions. For example, after the go-live of the core finance and purchase-to-pay
functionality, the program will transfer the finance team (to include subject matter experts and project
managers) into maintenance and operations, which may require a different organizational structure to
provide ongoing system support.
For consultants, the program will align the contract lengths and needs with the program’s staffing
requirements. This will enable an easy transition of contracted staff out of the program. As staff transition
off the program, the program director will coordinate appropriate roll-off steps with the business operations
manager. An Offboarding Checklist will be used to facilitate efficient off-boarding. This template is housed on
the program’s SharePoint site here.
Key steps include the following:
 Identify any remaining duties and transition these responsibilities to other staff
 Transition electronic files to the program’s document repository in accordance with state retention
laws and agency policies
 Return building security/access card
 Complete off-boarding form provided by the business operations section:
 Remove access rights to program documents and repositories

03/10/2021
 Remove access to all applications/systems
 Remove e-mail access
 Remove other network access
 Return of all state-owned equipment and property
As staff leave the One Washington program, they will be asked to complete a feedback form, and may also
be asked to participate in an exit interview with the business operations manager. All feedback forms are
optional and will be stored in a limited-access folder on the business operations SharePointsite.
A transition document will be created identifying the timing of the transition from a program position to an
operational position and will also include training and other requirements necessary for transitioning staff to
be successful in their new positions.
11.2.3.4 Staff Replacement

State staff vacancies are addressed through the established state hiring process. The program director will
work with the business operations manager to advertise positions and perform interviews in compliance
with state policies and procedures.
Vendor resources are replaced in accordance with the procedures established within their contract or
through established competitive procurement processes (please see the vendor management plan). Any
replacement of a contract position must meet the original minimum qualifications for the position andmay
be subject to an interview in addition to a review of their resume and qualifications. Prior work references
may be checked as part of the hiring process. Where possible, the replacement staff will begin work prior to
the original staff’s departure to help ensure appropriate transition of responsibilities and knowledge.
11.2.4 Resource Development

As new program staff are hired, various forms of training and education will be required to help new staff
ramp-up on the program and step into their assigned roles. The individuals hired will be expected to have
the basic qualifications, knowledge, skills, and abilities needed to fulfill their respective position
requirements.
Individual training and program organizational development (e.g., formal training, on-the-job, coaching,
mentoring, team skills, etc.) will be provided as needed to educate the individual on program-specific items
or job-specific tasks. The program is also creating an organization development program aimed at providing
long-term team skills that will contribute to each employee’s role within the program and help retention.
11.2.4.1 General Training Needs

To help onboard an individual, the following topics are important for all staff to know. The program director,
business operations manager and the first-line supervisor will be the accountable leaders ensuring that each
new One Washington program employee receives proper orientation and general training.
 General
o One Washington program overview
o Program governance and organizational structure
o Program meeting schedules

03/10/2021
 Administrative
o OFM policies and procedures
o Timekeeping and expense reporting (where required)
o Building/facility layout
o Emergency procedures
 Funding and financial management
o Overview of funding request processes - investment plan, decision packages, etc.
 Project management processes
o Organizational overview – functions, roles, responsibilities
o Status reporting – tools, templates, and process
o Issue/risk management – tools, templates, and process
o Change management – tools, templates and process
o Quality management – role of QA, OCIO and PMO
o Schedule management
o Document/deliverable management – tools, template, and processes
o Vendor management
 Project technologies
o SharePoint and Basecamp overview and instruction
o Other tools as needed for specific job duties (e.g. MS Project, Visio)
 Technical information
o Systems and technologies information
 OFM specific knowledge areas
 Safety and security training
11.2.4.2 Specific Training Needs

While the general training above will be provided to all staff to the level appropriate for each position,some
specific training may also be required by position. This specific training will be included in the individual’s
onboarding process once it is defined. All formal training requests will go through the business operations
section for funding approval.
11.2.4.3 Training Methods

The following methods will be used to train staff members:
 Presentation/meeting
 On-the-job training/intern program
 Coaching/mentorship program
 Learning Management System (LMS)
 Specific discipline self-study
 LinkedIn Learning
11.2.4.4 Responsibility for Providing Training

The first line supervisor will be responsible for overseeing the training of new members of the program
team. The business operations manager will facilitate organizational presentations and meetings important
for all team members. Peer staff currently onboard will mentor and provide on-the-job training to new staff.

03/10/2021
11.2.5 Performance Reviews
The first line supervisor will review each team member’s assigned work activities at the time of hire and
communicate all expectations of the work to be performed. The staff member’s direct supervisor will be
responsible for conducting annual performance evaluations, to include how effectively they are completing
their assigned work. The business operations section will provide the necessary guidance and tools to
perform the evaluations (please see OFM policy 2.11 performance management for additional information).
Periodic performance reviews will also be conducted of contracted staff, and a recommendation for
replacement will be made for those staff unable to meet the requirements of their role: please see the
Vendor Management Plan for further information. This recommendation will be followed by the necessary
steps outlined in their contract to release them and onboard replacement staff if required.
11.2.6 Project Team Training and Skills Acquisition

The table below summarizes the skills the project team needs to effectively fulfill their project assignments:
Table 37. Project Team Training and Skills Acquisition
# Skills Needed Target Roles Training Project Phase

Delivery Needed
Approach
1 Project Management Center Project team Virtual Imagine/Plan
(PMC) usage (RAID) Class/Demo
2 OFM-OneWa SharePoint and Project team Virtual Imagine/Plan
Microsoft Teams Class/Demo
3 Workday Demo Project Team Virtual Imagine/Plan
Class/Demo
4 Others TBD
Training plans and a log of their execution are maintained in the “Project Team Training Log” that is
documented for each specific training class. The living “Project Team Training Log” will be posted and
maintained in the PMO folder on the One Washington SharePoint site.
11.2.7 Resource Plan

The Resource Plan specifies the One Washington project resources needed by type (skills/competencies),
levels, and required dates, and is based largely on the staffing requirements defined in the project proposal
and confirmed when developing and managing the project schedule.
The Resource Plan is a dynamic document used to facilitate the planning, acquisition, and management of
the project’s staffing needs. Because it is frequently updated to reflect progress and forecasts, the Resource
Plan is maintained outside of the Project Management Playbook and will be stored in the PMO folder in
SharePoint.

03/10/2021
11.2.8 Project Team Onboarding and Offboarding
This section covers the items that need to be completed when a new project team member onboards onto
the One Washington project, as well as the protocols that must be followed when team members roll off the
project.
11.2.8.1 Onboarding Steps

 Request PMC and SharePoint site access
o Where applicable, request a One Washington email account and laptop
 Review the Core Project Team Launch Deck (dated 01/13/21)
 Review One Washington Onboarding Deck
 Review Project Management Playbook
 Complete the One Washington Onboarding Checklist and submit to the PMO
All of these documents reside in the PMOOnboarding folder: <provide link>
11.2.8.2 Offboarding Steps

 Review and confirm that no sensitive project documentation is on your state-issued and/or Deloitte
laptop
 Where applicable, prepare and turn in your state of Washington laptop and/or other equipment
 Complete the One Washington Offboarding Checklist and submit to the PMO
See the PMOOffboarding folder for more information: <provide link>
11.2.9 Resource Project Compliance

<What should be addressed here?>

03/10/2021
12. Project Tools Strategy Plan
12.1 Project Tools Strategy Overview

This section defines what tools will be used to facilitate and support the project. The Project Tools Strategy
defines the project tools selected for the project and how they will be used, project tool ownership and
point-of-contact (POC), and how the tools will be setup, accessed, supported, and decommissioned at the
end of the project.
The Project Tools Strategy took into consideration the One Washington project Workday implementation
approach, as well as the State’s existing project tool suite and long-term vision for project tools supporting
the solution, as well as the overall integration requirements for the project tools that will be used.

03/10/2021
12.2 One Washington Project Tools Map and Responsibilities
12.2.1 Deloitte In-Scope Tools
The table below defines the Deloitte In-Scope Tools that have been accepted by OFM for use during this project, in accordance with the terms and
conditions of the project SOW.
Table 38. One Washington Project Tools Map and Responsibilities
Name Point-of- Purpose and Usage Access Data Handling Left

Contacts Behind
(POCs)
Hoover Deloitte Finance Hoover for Workday is a proprietary data Installed on State VM. Access to the VM is OFM Records and Data is stored in the No
Team – upload utility that can be used to support the controlled by State and can be restricted to Hoover data store on the State VM.
Individual TBD conversion process beyond Informatica, the State laptops used by the Contractor
automating the loading of templates and Project team. Access to State sFTP server to pick up
State: perform validation on the converted data. It data and to store status/error reports on
Mistyjean allows us to iteratively refine the translation Hoover will access OFM Records and Data conversion.
Brown and Dan and conversion process through successive on an sFTP site, perform the appropriate
Ward conversions and to drive to a more rapid conversion activities and move the data to
and predictable conversion event with Workday.
production data at Go-Live.
This requires a point-to-point connection to
the Workday tenant to be loaded.
Access is to Deloitte only.

Rover Deloitte Finance Rover is Deloitte’s propriety, automated Installed on State Virtual Machine (VM). OFM Records and Data is stored in the No
Team – pre-conversion data validation tool. Deloitte Access to the VM is controlled by State and Rover data store on the State VM.
Individual TBD manages this tool with inputs from the State can be restricted to the State laptops used by
to ease data validation efforts after the Deloitte project team.
State: conversion.
Mistyjean Rover will access OFM Records and Data on
Brown and Dan an sFTP site, perform the appropriate
Ward conversion activities and move the data to
Workday.
State and Deloitte will utilize this tool.

Deloitte Finance Proprietary tool that accelerates the Access is for Deloitte team only Data at rest is encrypted using
Team – comparison of large volumes of data, used Advanced Encryption Standard in
Individual TBD extensively for payroll compare test Java based application hosted on AWS- Galois/Counter Mode (AES_GCM)
CompareEdge Cloud Platform with 256 bit secret keys and data in No
Provides variety of reporting capabilities to transit (HTTPS 443) is encrypted using
quickly identify root cause of discrepancies Utilizes Web Application Firewall which TLS 1.2 or above
prevents applicational layer attacks such as,
Page 144 of 169
Contacts Behind
(POCs)
State: One Washington Payroll legacy payroll data cross-site forgery, cross-site-scripting (XSS), Minimal personally identifiable
Mistyjean and One Washington Workday payroll data file inclusion, and SQL injection information (PII) is stored in
Brown and Dan are loaded into CompareEdge. CompareEdge: employee ID numbers
Ward CompareEdge compares the data providing and pay amounts
reports on discrepancies. Reports are then
downloaded to the sFTP for analysis by the Once a project is completed, data and
One Washington project team. reports in the tool can be downloaded
archival purposes and then securely
and completely purged from the
system.
ThinkTank™ Deloitte Finance ThinkTank is a collaboration tool that Web based third-party tool with access Discussion topics like business process No
Team – supports objective definition, requirements provided by Deloitte team. detail is presented through in the tool.
Individual TBD collection, design, implementation review Survey data, questions and parking lot
by creating an open and structure online State team access is provided by the Deloitte logs can be captured in tool and
State: forum for project and program success. team. exported to issue tracking tools for
Mistyjean resolution and use in design.
Brown and Dan
Ward Deloitte team to utilize State-provided Downloads on State machines and
machines for access. moved to State servers
Project Deloitte PMO – Our standard project management Web based tool hosed by Contractor. Access No OFM Records and Data will be No
Management Individual TBD information system (PMIS) for managing is provided by Contractor and is secured with stored in PMC.
Center (PMC) risks, action items, issues, and decisions MFA also.
State: (RAID) items for an implementation project One Washington project RAID items.
Mistyjean within the PMO. Access is for the State and Deloitte project
Brown and Dan teams. and possibly a few Agency SMEs
Ward Based upon the MicroFocus Project and needing access.
Portfolio Management (PPM) tool, PMC
facilitates consistent, accurate RAID
management and reporting. It can also
facilitate work plan and CR management
for a project, but these items are out-of-
scope for the One Washington project.
ALM - Deloitte Finance Octane is a cloud-based application Web-based tool hosed by Deloitte. Access is No OFM Records and Data is stored in No
Octane Team – lifecycle management (ALM) platform that provided by Deloitte and secured with MFA Octane.
Individual TBD will enable the One Washington also.
workstreams to collaborate on ** As part of a user story/test case, an
State: configuration, integration development, Access is for the State project team and employee ID or some other reference
Mistyjean reporting and other project tasks. Agency key users involved in testing may be made to OFM Records and
Brown and Dan activities. Data.
Ward Octane will also be used to plan, execute
and manage all Workday testing activities.
Page 145 of 169

Contacts Behind
(POCs)
AccordGrid Deloitte Finance AccordGrid plots the value and effort across Excel spreadsheet add in. No confidential OFM Records and Yes*
Team – a set of reporting requirements and visually Data will be used or impacted.
Individual TBD displays the results in a quadrant view that
enables quick and decisive planning.
State: AccordGrid can help measure the effort and
Mistyjean value involved with a given requirement.
Brown and Dan The use case is to prioritize the list of
Ward reports needing to be built and identifying
Deloitte versus State team for
implementation.
*AccordGrid constitutes Pre-existing Materials (as defined in the Umbrella Terms and Conditions) and is licensed to OFM pursuant to Section 29.2(c)
of the Umbrella Terms and Conditions).
12.2.2 State In-Scope Tools

The SOW also specified the following software tools will be provided by the State for use by designated users authorized by OFM in compliance with
the third-party licenses applicable to such OFM-provided software tools.
The POCs for all State project tools will be the following Technical Team members:
 Mistyjean Brown (Primary)

 Dan Ward (Secondary)
Table 39. State In-Scope Tools
Name Purpose and Usage Access Data Handling Target Project

Phase Tool will
be available
sFTP Server It is important in a cloud implementation to
protect OFM Records and Data. A secure FTP
server is required to be set up within State’s
firewall to support the conversion process
into Workday.
VPN Access Deloitte’s approach to implementation will have
consultants in remote locations performing tasks
that require access at times to State’s network.
Collaboration Software and license rights for designated
Toolset Deloitte personnel to use Basecamp and
Page 146 of 169
Name Purpose and Usage Access Data Handling Target Project
Phase Tool will
be available
Microsoft Teams – supporting team
communication, document storage, and
collaboration.
Development Software and license rights for designated

Toolset Deloitte personnel to use Basecamp and
Microsoft Teams and the data conversion and
developers’ tools.
Windows Deloitte Hoover conversion toolset requires
Virtual installation within the State’s network.
Machines and
Windows Virtual Machines are required for
Applicable
Software this installation.
Automation Deloitte’s Workday BOTs require this

Anywhere software to be running in the State’s
environment to utilize.
Articulate Tool to support the creation of learning
Storyline 360 content.
InformaticaTM Server and access are provided by State for
use on State-provided laptops.
Implementation Proprietary repository of Workday

BOTs implementation BOTs used to facilitate
tenant builds, automated regression testing
and chart of account mapping/translation.
Used to automate processing and can be run
internally or via Cloud.
Page 147 of 169

Support for all State-supported tools is available at: https://inside.ofm.wa.gov/it-systems/it-help
Any additional software will be agreed upon between the State and Deloitte as needed throughout this
project.
Deloitte personnel may conduct work on the project using devices issued to them by the State, both on-site
in Olympia and offsite at Deloitte or home offices. The State will provide reasonable access to State assets
required to fulfill the requirements of the project, including the sFTP server for conversion and shared
document repositories.
12.3 Project Tools Implementation Plan

The high-level project tool implementation schedule for the One Washington project is illustrated below.
Specific details of the activities and tasks involved in standing up the tools for the project will be defined,
tracked and monitored in the Project Work Plan/Schedule.
12.4 End-of-Project Tools Plan

As part of One Washington legacy system dispositioning/decommission, details on how project tools will be
shut down/decommissioned will be provided.
Any OFM Records and Data in Deloitte tools that will be decommissioned at the end of the project will be:
(1) Exported to the State for retention at the conclusion each tool’s project use or end of the SOW,
following the State’s instructions
(2) Cleared and sanitized from all such tools, employing sanitization and clearing processes acceptable
to comply with the National Institute of Standards and Technologies Guidelines for Media
Sanitization (NIST 800-88 Revision 2)

03/10/2021
13. Project Status, Internal Communications and Meeting Management
This section covers three key components needed for a successful One Washington project:
(1) Project Status meeting cadence and plans

(2) Project Stakeholder Engagement
(3) Internal Project Communications
13.1 Project Status Meetings

The table below defines the weekly and monthly occurrences for key project meetings:
Table 40. Project Status Meetings
Monday Tuesday Wednesday Thursday Friday

Weekly Weekly PMO
Workstream Meeting
Meetings 2-2:45 PM PT
Week 1
Weekly Weekly PMO Executive RAID Status

Workstream Meeting Steering Meeting
Meetings 2-2:45 PM PT Committee 2-3 PM PT
Week 2
Meeting
Weekly Weekly PMO Business
Workstream Meeting Transformation
Meetings 2-2:45 PM PT Board Meeting
Week 3
Weekly Weekly PMO RAID Status

Workstream Meeting Meeting
Meetings 2-2:45 PM PT 2-3 PM PT
Week 4
Weekly Weekly PMO Executive

Workstream Meeting Steering
Week 5 Meetings 2-2:45 PM PT Committee
(where Meeting
applicable)
Weekly Monday Workstream meetings include the workstreams conducting planning and execution work
and depend upon the stage/phase of the project. For example, during the Plan/Imagine phase, Monday
workstream meetings are being conducted by the PMO, Functional, and Architecture and Security teams.
13.2 Project Stakeholder Engagement

The One Washington project will continue to follow the protocols outlined in the One Washington
Stakeholder Engagement Plan developed and submitted by the One Washington OCM Team as part of SOW.

03/10/2021
The One Washington program currently engages its stakeholders in several ways, primarily through monthly
meetings with different stakeholder groups and engagement with Agency Support Teams (ASTs; as well as
through meetings with different One Washington governance bodies, including the ESC, BTB, and Business
Advisory Groups. The program coordinates with AST Leads directly for agency readiness requests via the
Agency Readiness Checklist (ARC) which is updated monthly to reflect upcoming activities and deadlines.
Since the One Washington transformation is statewide, success of the program relies heavily upon all
stakeholder groups being thoroughly engaged and prepared for change. The Stakeholder Engagement Plan,
along with the Communications Plan, provides the One Washington program with a strategic and proactive
approach to communicate key messages with stakeholders to align during the transformation. It provides
key messaging for stakeholder groups based on their unique high-level impacts, attributes, concerns, and
information needs, and it recommends tailored engagement activities for impacted stakeholders.
Another key component of the One Washington Stakeholder Engagement Plan is the design and
implementation of the High Impact Agency Approach. Based on an analysis of people, process, and
technology impacts included in Phase 1a, the program team has identified three tiers of agencies that are
considered “high impact” and require more frequent planning meetings and coordination based on size,
complexity, influence, and other unique characteristics. The program is engaging them through a series of
high impact meetings and the use of “relationship managers” to guide the activities of Tier 1 agencies.
Planning and managing stakeholder involvement for the project is vital to meeting project goals and
objectives, particularly when external resources can influence the direction or outcome of project results.
Please see the One Washington Organizational Change Management (OCM) Plan for overall stakeholder
management plan for specific stakeholder management activities of the Workday Phase 1A project.
13.3 Project Internal Communications

The table below defines the plan for project status reporting, addressing the needs of identified
stakeholders.
Table 41. Project Internal Communications
Chairperson/
# Communication Description Audience Frequency
Responsibility of
1 Project Status Meeting Regularly scheduled  Program Director Weekly Deloitte Project
meeting to update  PMO Leads (Tuesdays), Manager
project leadership on  Team Leads through
project progress and project
status. Information closure
presented:
Schedule
performance
Milestone progress
Deliverable status
RAID items that need
attention
03/10/2021
Chairperson/
# Communication Description Audience Frequency
Responsibility of
CR updates
2 Project Status Distribute standard  Project leadership Weekly PMO
Distributions status report after the
 Team Leads
weekly status
meeting, and/or post
in the appropriate
folder on the
SharePoint site
3 Project Phase Kick-off Formal kick-off of next  All project team TBD PMO with
Meetings project stage members sponsorship from
leadership
13.4 Meeting Management

Productive project meetings start with an agenda that defines the meeting purpose, attendees, and topics,
and clearly states the meeting objectives and desired outcomes. This section defines a process and
guidelines to support effective, well-managed meetings and meeting documentation.
The following criteria determine when a One Washington meeting requires planning, an agenda and meeting
minutes following the standard One Washington project meeting minutes template: <provide SharePoint link
to One Washington standard meeting minutes template>
 Meeting involving 4+ project stakeholders and cross-functional workstreams

 Meeting including any leadership/member participation from Governance Levels 2-5: i.e., Advisory
Committees, BTB, ESC and/or executive sponsor
 Others?
13.4.1 Meeting Roles and Responsibilities

Below are the key roles and responsibilities of a formal project meeting:
Table 42. Meeting Roles and Responsibilities
Meeting Leader  Plans, prepares, and conducts meeting
 Assigns a meeting scribe
 Ensures the meeting starts and ends on time
 Reviews and approves meeting minutes
 Reviews risks and issues
 Ensures risks, issues, and action items are documented in PMC and assigned with
agreed upon due dates
 Summarizes outcome of the meeting
Meeting Attendee  Prepares for and participates in the meeting

03/10/2021
 Reviews and provides additional inputs to meeting minutes, if necessary
 Sends a proxy if he/she is unable to attend the meeting (applicable to required
attendees)
Meeting Scribe  Prepares for and participates in the meeting
 Takes attendance
 Documents key discussion points, decisions, action items, and next steps
 Sends out the minutes and posts the final document on SharePoint
Meeting Proxy  Serves as a representative for a key invitee if he/she is unable to attend the
meeting
 Provides content knowledge for the meeting on behalf of the key invitee
 Prepares for and participates in the meeting
 Reviews and provides additional inputs to meeting minutes, if necessary
 Provides information from the meeting to the meeting invitee for whom he/she
served as proxy
13.4.2 Meeting Guidelines for Success

The following are some general codes of conduct to help make One Washington meetings more effective
and efficient:
 Commit to the meeting timeframe

 Arrive on time
 Laptops down (unless using it to present)
 Silence audible alerts on all mobile devices
 Refrain from using mobile devices during meeting
 Represent your area – silence is agreement
 Focus on issues, not people
 Avoid sidebar conversations
 Avoid tangents – anyone can call a “yellow flag” or “parking lot”
 Manage time allotted for each agenda item
 In these pandemic/virtual meeting times, uphold virtual meeting etiquette practices
13.4.3 Meeting Process

Below is a standard 7-step meeting process that should be followed in order to plan, execute and document
effective meetings:
Step 1: Plan for meeting and send out invite
Responsibility: Meeting Leader
 Determines the topics to cover and the best format to discuss each of them
 Creates an agenda

03/10/2021
 Selects attendees to participate in the meeting
 Highlights roles and responsibilities of key meeting attendees, assigns a meeting scribe, and includes
this information in the agenda
 Schedules a conference room equipped with laptop and projector, if needed, for effective facilitation
 Sends the meeting invite with agenda in advance enabling attendees to prepare for the meeting
 Sends the minutes from the previous meeting (if applicable), and when required, any documents that
will be reviewed/discussed at the meeting
Guidelines:
 Include the meeting objective(s) in the meeting invite

Step 2: Respond to invite and prepare to attend meeting
Responsibility: Meeting Attendees and Meeting Scribe
 Responds to the meeting invite

 Delegates a suitable proxy to participate in the meeting, if unable to attend
 Clarifies the purpose and/or anticipated outcomes of the meeting, if necessary
 Prepares for the meeting
Step 3: Prepare for and conduct meeting
 Delegates a suitable person to conduct the meeting if unable to attend on the scheduled day or
reschedules the meeting
 Defines the objectives and desired outcomes in preparation for the meeting
 Ensures meeting starts on time
 Facilitates the meeting, follows the agenda, and manages the time for each topic
 Reviews action items from the last meeting and validates completion
 Identifies risks and issues and validates the information with attendees
 Clarifies and paraphrases key ideas and decisions
 Identifies next steps and assigns roles and responsibilities for each
 Identifies action items, action owner, and due date for each
 Reviews action items, next steps, decisions, issues, and risks raised at the meeting with the team
 For a non-recurring meeting, sets a tentative date for the next meeting, as needed
Guidelines:
The following checklist is provided on the upper right corner of the Meeting Agenda Template to assist the
Meeting Leader, as needed.
 Start on time
 Review agenda
 State meeting purpose and objective(s)
 Solicit risks and issues
 Record all RAID items in PMC (or capture in notes for entry into PMC later)
 Summarize key points and takeaways from the meeting
 End on time and thank participants

03/10/2021
Step 4: Participate in meeting
Responsibility: Meeting Attendee and Meeting Scribe
 Participates in the meeting

 Discusses progress of the project/workstream/business area and provides status updates
 Discusses action items assigned during last meeting and provides a status update
 Identifies risks and issues and provides an update on risks and issues that he/she owns
 Identifies lessons learned
Step 5: Capture meeting minutes and send for review
Responsibility: Meeting Scribe
Documents the following in the meeting minutes:
 Attendance
 Key points of the meeting in summary bullets
 Key RAID items identified, updated or closed during the meeting (in either PMC directly, or in
minutes for PMC entry/updates later)
 Key lessons learned and next steps
 Sends the minutes for review to the leader within 24 hours after the meeting
Step 6: Review and approve minutes
 Reviews the meeting minutes

 Identifies any missing actions, decisions, or next steps
 Provides additional comments
 Approves minutes, sends final to meeting scribe to post on SharePoint, within 1 business day
Step 7: Post final minutes to SharePoint and update action items
Responsibility: Meeting Scribe
 Incorporates inputs received from meeting attendees and leader and updates the minutes as needed
 Posts the final minutes to SharePoint
 Updates action items on SharePoint
 Notifies the team about the updates and posting of minutes on SharePoint

03/10/2021
14. Quality Management Plan
14.1 Quality Management Overview

This section defines the objectives, roles and responsibilities, processes and tools needed to deliver a high-
quality Workday solution for the One Washington program.
The objectives of this Quality Management Plan (QMP) are to:
 Define the One Washington project quality objectives, roles and responsibilities
 Define the plans for formal Quality Assurance (QA) reviews for the One Washington project
 Define the approach to verify that the methods, processes, templates and tools developed for the
One Washington project are being consistently used by the project team properly, and they are
effective
 Define the approach to verify that One Washington project deliverables are meeting project
standards and quality expectations
 Describe how quality will be monitored, controlled and reported on the One Washington project
 Describe the plans for continuous improvement and capturing lessons learned from the One
Washington project
14.1.1 Verification Versus Validation

Verification focuses on work products that define the requirements, configuration, integration and
implementation of the One Washington Workday solution and is executed primarily through walkthroughs,
inspections and milestone reviews. Verification evaluates whether a product complies with project-defined
standards and business requirements.
Validation is a quality process for confirming that a work product or service satisfies its intended
requirements upon migration to the production environment. It is usually confirmed by different types of
pre-migration testing (e.g., parallel testing, user acceptance testing or UAT, and readiness testing). The One
Washington project Testing Strategy deliverable details the types of testing planned for the project.
14.1.2 Quality Assurance Versus Quality Control

For clarity, the table below explains the differences between quality assurance and quality control:
Table 43. Quality Assurance vs. Quality Control
Quality Quality
Assurance Control
Definition A set of activities for ensuring quality in the A set of activities for ensuring quality in
processes by which products are developed. products. The activities focus on identifying
defects in the actual products produced.
Focus PROACTIVE REACTIVE

03/10/2021
Considerations  Establish a good quality  Finding and eliminating sources of
management system and the quality problems through tools and
assessment of its adequacy. processes suchthat customer
 Perform periodic conformance requirements are continuallymet.
audits of theoperations of the  The activities or techniques used to
system. achieve and maintain the product
 Prevention of quality problems quality, process and service.
through planned and systematic  Defect repair and measurement of
activities including documentation. quality indicators.
 Initiate corrective or preventive
action as a result of the audit.
Tools  Standards and metric development  Assessment and reporting of
 Deliverable Expectation Document metrics
(DED)  Checklists
 Peer reviews or stakeholdering  Process and stage-gate audits
 Testing inspections
 Deliverable review
14.1.3 Quality Management Principles

The following quality management principles have been adopted by the OneWashington program:
 Customer focus: Organizations can establish this focus by trying to understand, meet or exceed their
customers’ current and future requirements and expectations.
 Leadership: Organizations succeed when leaders establish and maintain the internal environment in
which employees can become fully involved in achieving the organization’s unified objectives.
 Involvement of people: Organizations succeed by retaining competent employees, encouraging
continuous enhancement of their knowledge and skills, empowering them, encouraging engagement
and recognizing achievements.
 Process approach: Organizations enhance their performance when leaders manage and control their
processes, as well as the inputs and outputs that tie these processes together.
 System approach to management: Organizations sustain success when processes are managed as
one coherent quality management system.
 Continuous improvement: Organizations maintain current levels of performance, respond to
changing conditions, and identify, create and exploit new opportunities when they establish and
sustain an ongoing focus on improvement.
 Factual, metrics-based approach to decision-making: Organizations succeed when they have
established an evidence-based decision-making process that entails gathering input from multiple
sources, identifying facts, objectively analyzing data, examining cause/effect, and considering
potential consequences.
 Mutually beneficial vendor and partner relationships: Organizations that carefully manage their
relationships with vendors and partners can nurture positive and productive involvement, support
and feedback from those entities.
One Washington has established a number of processes and best practices that focus on these principles.
These include inclusive governance groups and processes, project management processes to establish
monitor, and control scope, schedule and budget, risk and issue management processes, and the
establishment of a PMO to cohesively manage these processes.
03/10/2021
14.2 Quality Management Roles and Responsibilities

The table below describes the quality roles and responsibilities for One Washington project team members:
Table 44. Quality Management Roles and Responsibilities
Project Manager  Review and approve the Quality Management Plan section of the Playbook
 Review quality and Deloitte engagement review findings
 Assign project team members to appropriate action items resulting from
quality assurance reviews, quality reviews, and other adviser
recommendations; monitor and manage those action items to closure
 Track engagement review and quality action items to closure
PMO  Maintain the Quality Management Plan section of the Playbook
 Develop and maintain the quality review schedule for the One Washington
project
 Track quality improvement action items for the One Washington to closure
Team Members  Prepare for and participate in quality assurance reviews and Deloitte
quality reviews
 Implement action items resulting from quality reviews and Deloitte quality
reviews
Deloitte Quality  Perform engagement quality reviews
Reviewer  Review the findings with the project leadership team
 Follow up on action items from previous reviews
Workday Delivery  Plan and perform Workday DA reviews: Plan Stage, Integration, FDM,
Assurance (DA) Authentication, Configuration, Cutover, Operate
Reviewer  Review the findings with the project leadership and technical teams
 Follow up on action items from previous reviews
Oversight  bluecrane independent QA reviews
 OCIO Oversight
14.2.1 Implementing and Maintaining the Quality Management Plan

The One Washington PMO will oversee the Quality Management Plan for the project and manage its uptake
and maintenance. However, a truly successful implementation of the One Washington quality objectives is
the shared responsibility of the entire project team.
Throughout the project, the PMO will implement required revisions to the project’s Quality Management
Plan to keep it current and relevant throughout the One Washington project lifecycle.
14.3 Quality Assurance Plan

Quality assurance is the application of planned, structured activities to help verify that the project employs
all processes needed to create high-quality deliverables that meet requirements.
This section of the QMP describes how One Washington project quality is evaluated through QA reviews
performed to confirm that the project is making steady progress to deliver a high-quality solution on budget
and schedule.

03/10/2021
A key component of a quality assurance is to assess that processes and standards defined in approved plans
(such as this Project Management Playbook) for the project are being followed consistently and effectively
by the project team. This assessment is done by asking three questions:
 Are the documented project processes being followed?

 Are the documented project processes working?
 Are the documented project processes efficient?
The defined project processes subject to QA review are the following:
 Project Governance
 Schedule Management
 Cost Management
 RAID Management
 Risk Management
 Action Item Management
 Issue Management
 Decision Management
 Scope Management and Change Control
 Requirements Management
 Development Management
 Solution Development
 Document Management
 Resource Management
 Project Status Reporting
 Communications Management
 Meeting Management
 Quality Management
 Quality Control
 Personally Identifiable Information Handling
The PMO will check compliance with the defined processes as part of each of the:
 Regular PMO meeting to review key risks, issues, schedule, upcoming activities and late tasks
 Weekly schedule updates from vendors, and program leadership team members
 Risk and issue review meetings
 Governance preparation meetings to prepare proposed change requests and coordinate requests
across governance committees.
 Program management plan reviews to apply lessons learned and refine processes
As quality assessments are performed, it is up to project leadership to evaluate the results and determine
what, if any, corrective actions should be taken. Corrective actions might include (a) additional training, (b)
stronger process enforcement, or (c) process refinements. It is important to weigh the cost of process
changes versus their expected benefits before implementing them.
Three (3) formal QA review types are planned for the One Washington project:
1. Independent QA Reviews with Bluecrane, Inc. (referred to as “bluecrane”)

2. Deloitte Quality Reviews
03/10/2021
3. Workday Delivery Assurance
14.4 Independent QA Reviews with bluecrane

The Washington State Office of the Chief Information Officer Policy 132 requires all state projects designated
by the OCIO to have external, independent QA that reports to the project sponsor. A competitive
procurement was conducted in 2018 and bluecrane was awarded the QA contract. bluecrane produced the
Initial readiness assessment report in May 2018 and monthly assessment reports have followed and can be
found on the OCIO IT dashboard.
Each monthly assessment report includes observations, findings, recommendations and a risk rating in
specific program areas. The PMO is responsible for responding monthly to each of the recommendations.
The QA assessment report and PMO response report are posted to the One Washington Program’s OCIO IT
Dashboard and is available for public review.
bluecrane will conduct a readiness assessment at the beginning of each phase. For each assessment area,
bluecrane reports their assessment results and any issues and/or risks assessed over the last month, as well
as high-level recommendations for addressing the risks. They perform the following assessment:
 Planning – is the program doing an acceptable level of planning?

 Executing – assuming adequate planning has been done, is the program performing tasks in
alignment with the established program plans the program?
 Results – are the expected results being realized? A program that does a good job of planningand
executing those plans but does not realize the results expected by participating partners and other
stakeholders, is a less than successful program. Ultimately, results are what the program is all about.
One Washington is responsible for responding monthly to each of the recommendations. The QA assessment
report and PMO response report are posted to the One Washington Program’s OCIO ITDashboard and are
available for public review.
Deloitte project leadership will meet with bluecrane to discuss any observations or findings from their
reviews of the project, and will address any Deloitte action items or follow-ups, as appropriate. Deloitte will
support the audit of any One Washington Workday production release performed by bluecrane, by allowing
access to processes, data, deliverables, staff, resources and tools to verify that as-built functionality and
configuration meet contractual requirements. In addition, Deloitte will also make staff, resources, processes,
data, tools, and deliverables available to bluecrane for reviews, walkthroughs, audits and inspections, as
appropriate.
14.5 Deloitte Quality Reviews

Deloitte Quality Reviews are completed every 3-4 months to assess compliance with the One Washington
program and Deloitte standards. Non-compliance items will be logged and tracked to resolution as action
items or issues in PMC.
Deloitte Quality Reviews are formal, objective, onsite reviews (if possible, with Covid; otherwise it will be
virtual) conducted by a seasoned Deloitte executive outside of the immediate One Washington project
leadership team who evaluates the status of the project in six categories:

03/10/2021
 Project leadership
 Solution and deliverables
 Estimation, planning, and timeline
 Project staffing
 Monitor and control
 Approach
Deloitte Quality Reviews follow a defined process and toolset to document and report their findings back to
the project team, which can include client project leadership.
An initial Deloitte Quality Review Plan is defined in the table below; this plan will be approved and
maintained with One Washington program State leadership:
Table 45. Deloitte Quality Review Plan
Type of Project
# Reviewers Frequency Objectives
Review
1 Initial Quality Quality Review Within 3 months of  Define the project quality review schedule
Review (QR) executive project kickoff per major project milestone dates and
phase transitions
 Introduce project Quality Review executive
and purpose of reviews to client leadership
 Review the project per the six quality
review categories as they relate to project
mobilization
2 Regular Quality Quality Review Every 3 months, or  Follow up on all previous concerns and
Review schedule executive at major project recommendations
milestones  Assess the project against the six quality
review categories as they relate to the
current project phase
3 Pre-Go-live Quality Review One-time  Review testing status and metrics

Quality Review executive  Review data conversion status and
readiness
 Review training status and people readiness
 Review Go-live tactical plans and checklists
 Review backup and contingency plans
The Deloitte Quality Review executive for the One Washington project will be:
 Christina Dorfhuber
 cdorfhuber@deloitte.com
 303-312-4105

03/10/2021
14.6 Workday Delivery Assurance

The Workday ERP software provider also has a quality Delivery Assurance program to help verify and validate
that the solution architecture and configuration designed and developed for One Washington will operate
smoothly and efficiently in their application. Deloitte will work with the State and Workday to define an
appropriate Workday Delivery Assurance review schedule.
14.7 Quality Control Plan

Quality control involves monitoring project-specific results for quality, and identifying corrective, preventive,
or improvement actions when results are unsatisfactory or do not meet expected standards and
requirements.
14.7.1 Deliverable Management

Deliverable management defines the set of activities the One Washington project will uses to plan, draft,
review, and obtain State approval for project deliverables. A key aspect of assuring quality deliverables is
performing appropriate peer reviews.
The term ”deliverable” applies to a formal output of an activity defined in the Statement of Work on which a
payment depends. Deliverables are distinguished from “work products” which are activity outputs that do
not require formal review nor approval.
The deliverables management process includes the following components:
 Assignment of responsibilities for each deliverable

 Deliverable Expectation Document for each deliverable
 A formal process for review, comment and deliverable decisions with formal notification of
deliverable decision
One Washington project deliverables will follow the DefineDevelopReviewApprove Process described
in the Figure below:

03/10/2021
Figure 29. One Washington Deliverable Process
14.7.2 Deliverable Responsibilities

There are five primary roles involved in the production, review and acceptance of deliverables. These roles
with their responsibilities are listed in the table below. The PMO will work with the deliverable owner to
assign roles for each deliverable and validate assignments.
Table 46. Deliverable Management Roles and Responsibilities
Role Responsibilities
Deliverable Owner  Review and approve the Deliverable Expectation Document (DED)
 Act as central point of contact during deliverable development/review
process for vendor and One Washington resources
 Complete assessment of deliverable readiness for walk-through
 Attend walk-through
 Review deliverable/prepare written comments (along with other
Reviewers)
 Consolidate/Reconcile Reviewer and contributor comments and submit a
single set of comments to the vendor
 Return individual comment forms with resolution noted to Reviewers;
Forward final comment form with resolution from the vendor
 Indicate acceptance, acceptance with conditions or rejection of deliverable
by signing the Deliverable Acceptance Document.
 Verify conditions have been satisfied when a deliverable has been accepted
with conditions.
 Verify deficiencies are corrected and acceptance criteria met with
approvers when a deliverable is non-accepted
 Notify Reviewers when deliverable is ready for review and Approver when
deliverable is ready for acceptance
 Consult with producer during deliverable preparation process to avoid
concerns/issues late in the process
Producer  Develop initial and final DED orientation session
 Coordinate deliverable development with Deliverable Owner
 Conduct content development sessions
 Develop initial and final deliverable
 Conduct walk-through
 Submit deliverable for formal review and acceptance

03/10/2021
Role Responsibilities
 Incorporate compiled/reconciled comments
 Complete Resolution Section of the Comment form and return to
Deliverable Owner for distribution
 Complete any conditions of acceptance or deficiencies that resulted in non-
acceptance.
Contributor  Provide input to development of acceptance criteria
 Attend content development session(s) with the vendor
 Identify other Contributors, Subject Matter Experts, or background
materials to supplement content development
 Consult with producer during deliverable preparation process to avoid
concerns/issues late in the process
 Complete assessment of deliverable readiness for walk-through
 Review deliverable and prepare written comments (along with reviewers)
 Verify deficiencies are corrected and acceptance criteria met with
deliverable owner when a deliverable has been previously rejected
 Recommend acceptance or rejection of deliverable
Reviewer  Provide input to development of acceptance criteria
 Review initial and revised deliverable/prepare written comments
 Consult with Approvers during deliverable review process to avoid
concerns/issues late in process
 Recommend acceptance or rejection of deliverable
Approvers  Provide input to development of acceptance criteria
 Participate in the acceptance of the deliverable for conformance to purpose
 Attend walk-through/submit verbal comments (Optional attendee –
intended to orient Approvers to document)
 Consult with Reviewers and indicate acceptance, acceptance with
conditions or non-acceptance of deliverable, by sign-off
Deliverable  Schedule and attend content development session(s) with vendor and
Coordinator other Contributors
 Schedule and attend walk-through
 Update DED and deliverable status in SharePoint/Basecamp after each
step
 Maintain hard copies of DEDs and deliverables in the project library
 Maintain electronic copies of DEDs and deliverables in SharePoint
14.7.3 Deliverable Expectation Document

For deliverables, a DED is developed to ensure that the vendor and One Washington each have a common
understanding of the content, assumptions, risks and acceptance criteria associated with the deliverable
before work begins. The DED will also contain a timeline for delivery, review and acceptance of the
deliverable. The DED process begins when the producer creates a draft DED which consists of the following
components:
Table 47. DED Components
DED Component Description

Introduction,  Summary description of the deliverable to be developed, how the deliverable
Purpose, will be used, and the reference that establishes the requirement for the
Requirements deliverable

03/10/2021
DED Component Description
Assumptions and  Assumptions or risks critical to the development of the deliverable (e.g.,
Risks scope of deliverable, exclusions or inclusions, etc.)
Format  The format of the deliverable, as stipulated in the Statement of Work; that
is, Microsoft Word (.docx), Excel (.xlsx), PowerPoint (.pptx), etc.
Contents  A listing of the deliverable’s table of contents
Constraints  A statement on whether and how the deliverable is subject to the change
control process
Acceptance Criteria  Criteria that if met determine the One Washington acceptance of a
deliverable
Review and  The schedule for the deliverable production, review and acceptance process
Acceptance
Timeframes
Roles and  The roles associated with deliverable production, review and acceptance;
Responsibilities same table as the one above
14.7.4 Deliverable Review and Acceptance

The producer is responsible for assessing a deliverable’s readiness for formal review. The readiness review
will involve the producer and the owner. Based on the assessment, the owner may request remedies from
the producer before scheduling a walk-through with reviewers. Because the walk-through and subsequent
review process is time-consuming, it is important that the owner assess a deliverable for readiness before
beginning the formal review to ensure all deliverables are complete, accurate, and meet the defined
acceptance criteria.
Just prior to releasing the deliverable for formal review, the deliverable coordinator schedules a walk-
through. The walk-through provides an opportunity to orient reviewers to the deliverable, thus familiarizing
all attendees with the subject matter and facilitating/streamlining the overall review time. At the walk-
through, the producer will provide attendees with a high-level review of the deliverable, remind consumer
and reviewers of the acceptance criteria, and answer any questions.
After the walk-through, the producer will submit the draft deliverable for formal review to the consumer.
The deliverable coordinator logs the updated status in the project repository and releases the deliverable to
the consumer and reviewers for review. The deliverable is reviewed based on the acceptance criteria. For
contract deliverables, reviewers will have the time, designated within the DED, to complete the initial formal
review and to submit comments back to the consumer.
The producer will then consolidate and resolve each reviewer’s comments and submit a single set of
comments to the owner. The consolidation/reconciliation process may require the consumer to follow-up
with reviewers to resolve conflicting comments and to meet to discuss and resolve conflicts, when
comments are substantive.

03/10/2021
When the producer releases the deliverable for final review and acceptance, the deliverable coordinator will
again update the status of the deliverable and notify reviewers and the deliverable owner that the
deliverable is ready for final review and acceptance.
During this final review and acceptance cycle, reviewers should limit their comments to previously identified
comments. The intent is to encourage reviewers to identify all comments or issues in the first review cycle
and not to identify new material within the final review cycle. Consumers are encouraged to work closely
with the deliverable owner to ensure there are no additional concerns identified at this late stage. However,
if a substantive deficiency that does not meet the defined deliverable acceptance criteria is identified,
reviewers should include that in their final comments which could necessitate another revision to the
deliverable before submitting for acceptance.
All program artifacts are published under the auspices of the Office of Financial Management and subject to
public disclosure and therefore, must meet quality standards as defined by the One Washington program.
Deliverable owners have two (2) options in terms of deliverable acceptance:
1. Accept deliverable “as is”
2. Reject deliverable (some or all of the acceptance criteria have not been met)
If accepted, the deliverable coordinator will prepare a deliverable acceptance form and send it to the
contract manager and deliverable owner, for signature. Once signed, the deliverable coordinator will then
deliver it to the producer. The deliverable coordinator is responsible for ensuring that an electronic version
of the final, accepted deliverable and its supporting documentation is maintained in the project repository.
In the event that a deliverable is rejected, the specific deficiencies that do not meet acceptance criteria must
be included in the deliverable rejection form. The deliverable coordinator, working with the owner, will
prepare the notice of deliverable rejection and send it to the deliverable owner for signature. The
deliverable coordinator will then deliver the signed notice to the producer. The deliverable owner will follow
remediation steps to resolve the rejection.
14.7.5 Deliverable Peer Reviews

Peer reviews aim to detect defects. Before a One Washington deliverable is formally submitted for State
review and approval, peer reviews will be performed by the Deloitte project team to:
 Verify the completeness of a deliverable

 Verify the accuracy of a deliverable
 Verify that a deliverable meets project standards, as well as any deliverable-specific or custom
requirements
 Verify that the content of a deliverable meets its objectives, and is consistent with prior approved
deliverables (where applicable)
Deloitte has put in place a two-stage peer review process for the One Washington project.
1. Peer review
 Team member peer review
03/10/2021
 Author revises draft
2. Deloitte PMO leadership review
 PMO team and/or appropriate team lead reviews document for quality and State readiness
 Author revises draft and submits final draft to PMO for formal submission to the State
14.7.6 Workday Solution Development

In terms of developing the One Washington Workday solution, quality checks are built into the
configuration-confirmation iteration approach that will be used with the State stakeholders, as the solution
is continuously, reviewed, tweaked and confirmed.
For integration and reporting solution components, peer reviews are part of the development process,
including checks for alignment to the naming conventions and established standards for the One Washington
Workday solution. Please see the Integration Approach and Reporting Strategy and Approach deliverables,
as well as the <One Washington Workday Configuration and Naming Standards.docx> document for more
information.
14.7.7 Testing and Defect Management

Quality control refers to the activities performed to verify the quality of the program’s product. For One
Washington, the product is the implemented ERP system. Many of the quality control processes will be
performed by the system integrator and verified by One Washington staff or other external consultants hired
to perform independent QA. Quality control activities planned for One Washington include:
 System integrator software testing including testing Washington’s unique configurations

 Independent validation of vendor’s test results by a third-party consultant
 User acceptance testing by state staff
 System readiness assessment
The Deloitte team will conduct several types of testing to verify and validate that the solution fulfills
functional, technical and user experience requirements as defined in the RTM, culminating in the
deployment go/no-go decision. The types of testing will be the following.
 System testing will focus on ensuring that the installed software components and their unique
configuration for Washington state are functioning per the requirements;
 Integration testing will ensure the components are all working together as a single installed unit;
 Interface testing will verify that the inputs from external systems and outputs to external systems
are functioning per requirements;
 Performance testing ensures that the system will perform (on-line response time, report generation
response time, etc.) according to requirements; and
 End-to-end testing will test specific use cases or user stories from beginning of a business process to
the end of the process.
 End-user testing, where users verify that the functionality is acceptable based on the requirements
and their use cases.
Prior to the system integrator testing phase, the state and vendor will agree on entrance and exit criteria for
each testing phase.

03/10/2021
The Testing Strategy and Test Plan deliverables will detail the approach to testing, the types of testing to be
performed, test results compared to established standards and the involvement by state staff in the testing.
Deloitte will report the results of testing and provide evidence to One Washington that testing met
established standards and business requirements.
14.8 Quality Monitoring and Reporting

The QA review vendor bluecrane, as well as the Deloitte Quality Review process includes standard findings
reports as part of their QA reviews, including action items and/or corrective actions to address items that
need improvement from the project team.
The Requirements Traceability Matrix (RTM) provides another means of checking solution quality, by
capturing the mapping of test scripts, test cases, and test scenarios to the One Washington requirements.
The RTM provides the means to verify that all of the requirements are covered by test scripts: 100 percent
coverage is the goal.
Quality status will certainly factor into the weekly status reporting process: yellow or red status indicators
(on scope, schedule, RAID, or overall, for example) may be caused by a quality issue when root cause analysis
is applied. Thus project quality will be monitored, controlled, and reported on through weekly status
reporting. Please see Section 13 of this Playbook for more details.
14.9 Continuous Improvement and Lessons Learned

Quality improvement will be a continuous process on the One Washington project. The project team will
look for improvement opportunities throughout the execution of the project. At the end of each project
phase, the team will reflect on what quality processes and standards for the project worked well, and what
could be improved for the One Washington engagement. The project team will implement quality
corrections that come out of each end-of-phase debriefing process to prevent future issues in subsequent
phases.
14.9.1 Root Cause Analysis

Root cause analysis is a specific technique used to understand an issue or a problem: discovering the
underlying causes that led to it, and then developing corrective actions to resolve it, as well as preventive
actions to prevent it from happening again on the project. The outputs of root cause analyses can feed into
project lessons learned activities.
14.9.2 Lessons Learned

After each phase of the project, the project team will conduct meetings to identify and discuss “pain points”
experienced during that phase; then determine what lessons can be learned to avoid the same issues from
reoccurring in subsequent phases. Lessons learned also looks for practices that were done well, and should
be reinforced or repeated. The lessons learned details will be captured and documented for future
reference.
In summary, to efficiently implement the lessons learned approach, the Deloitte team evaluates all activities
in each phase to evaluate:
03/10/2021
1. QA/QC
Activities
2. Review
5. Apply
Current
Process
 What went well Improvements
Quality
Processes
 What did not go well
 What needs to change
4. Capture 3. Perform
Lessons Root Cause
Learned Analysis
Figure 30. One Washington Continuous Improvement Process
14.9.3 Continuous Improvement

During lessons learned meetings, the project manager and attending project team stakeholders share their
experiences and provide their inputs on project processes and standards. Based on the results of these
meetings and findings, project leadership and the PMO may need to adjust project standards and/or
processes in order to improve them and avoid future similar issues and pain points.
For example, extra quality/peer review checklist items may be defined as a result of comments from the
State or other project stakeholders regarding deliverable development. Then, during the next round of
deliverable submissions, the PMO will monitor whether the number of similar issues/comments have gone
down in number as part of continuous improvement measurement procedures.

03/10/2021
15. PII Handling
Personal information or personally identifiable information (PII) is any information relating to an identifiable
person. PII is Information which can be used to distinguish or trace the identity of an individual (e.g., name,
social security number, biometric records, etc.) alone, or when combined with other personal or identifying
information which is linked or linkable to a specific individual (e.g., date and place of birth, mother’s maiden
name, etc.).
The One Washington/Vendors Technical Requirements matrix in the Contract states that the PII data will be
covered by ISO 270018 and NIST800-53 for handling PII in the Cloud, through the Data Processing Exhibit,
controls in the SOC2 report, and formal mapping to GDPR.
The State will limit sensitive information, such as PII, trade secrets and other information that it considers
sensitive or highly confidential, it provides to Contractor (or otherwise makes available to Contractor) to only
that which is reasonably necessary to allow Contractor to provide the Services. Any PII security breach
notification statue as referenced from RCW 19.255.010 will comply with the incidents response process as
stated in this workbook, as well as processes and requirements defined in the Information Security and Risk
Management Plan (ISRMP).

03/10/2021

OneWa-003DEL-Project Management Playbook

Uploaded by

Document Information

Original Description:

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

OneWa-003DEL-Project Management Playbook

Uploaded by

Copyright:

Available Formats

One Washington (System Integrator K3298 SOW_1A)

Project Management Playbook

Project Management Playbook

Version 0.9 Page 1 of 169

Document Control General Information

Type of Information Document Data

Version 0.9 Page 2 of 169

Version Number Date Additions/Modifications Prepared/Revised By

Version 0.9 Page 3 of 169

Version 0.9 Page 4 of 169

Version 0.9 Page 5 of 169

Version 0.9 Page 6 of 169

Table 1. Project Team Roles and Responsibilities .................................................................................................... 12

Version 0.9 Page 7 of 169

Figure 1. One Washington Project Operational Chart.............................................................................................. 11

Version 0.9 Page 8 of 169

Version 0.9 Page 9 of 169

Version 0.9 Page 10 of 169

2.1 Project Operational Chart

Figure 1. One Washington Project Operational Chart

Version 0.9 Page 11 of 169

2.2 Project Team Roles and Responsibilities

Table 1. Project Team Roles and Responsibilities

Project Roles Key Responsibilities

Version 0.9 Page 12 of 169

Project Roles Key Responsibilities

Oversees work performed by the change and communications specialists,

Version 0.9 Page 13 of 169

Project Roles Key Responsibilities

Version 0.9 Page 14 of 169

Project Roles Key Responsibilities

Version 0.9 Page 15 of 169

Project Roles Key Responsibilities

Completes hands-on functional and technical project activities and provides

2.3 One Washington Program and Technical RACI Matrix

Version 0.9 Page 16 of 169

Version 0.9 Page 17 of 169

3. Project Governance Plan

3.1 Governance Framework

Figure 3. Foundational Governance Framework

Version 0.9 Page 18 of 169

3.1.1 Governance Guiding Principles

3.1.2 One Washington Project Governance Framework

Version 0.9 Page 19 of 169

Figure 4. One Washington Governance Framework

3.1.3 One Washington Governance Framework Level Descriptions

Version 0.9 Page 20 of 169

Version 0.9 Page 21 of 169

3.2 One Washington Governance Model

Figure 5. One Washington Governance Model

3.2.1 One Washington Governance Model Escalation Process and Thresholds

Version 0.9 Page 22 of 169

Table 2. One Washington Governance Model Escalation Process and Thresholds

Level Escalation Process Thresholds / Criteria

Version 0.9 Page 23 of 169

Level Escalation Process Thresholds / Criteria

Version 0.9 Page 24 of 169

3.2.2 One Washington Escalation Circuit-breaker Process

Figure 6. One Washington Escalation Circuit-breaker Process

3.3 One Washington Governance Charts

Version 0.9 Page 25 of 169

3.3.2 One Washington Governance Structure

Figure 7. One Washington Governance Structure