Project Management Playbook ___ - OCIO Dashboard

One Washington (System Integrator K3298 SOW_1A) Project Management Playbook

Version 0.9 of 169 03/10/2021

Project Management Playbook ___

March 10, 2021


Version 0.9 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


Version 0.9 of 169 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 4

Mike Baum/David Boeker

v0.3 02/03/2021 Revisions in Sections 3-4, new draft of Section 5

Mike Baum/David Boeker

v0.4 02/05/2021 New drafts of Sections 6-7 on RAID and CR Management

Mike Baum

v0.5 02/09/2021 Revisions in Sections 6-7; new drafts of Sections 8-9 on Reqs and Dev Management

Mike Baum

v0.6 02/16/2021 Some revisions in Sections 8-9; new drafts of Sections 10-13 on Document Mgt, Resource Mgt, Tools and Status and Internal Communications

Mike Baum

v0.7 02/25/2021 Revisions from working sessions during previous week, David R’s suggested edits, and initial content for Section 14 Quality Management Plan

Mike Baum/David Friedman

v0.8 02/26/2021 Final draft version for initial formal submission for review and approval


V0.9 03/10/2021 Revised version based on initial formal review Comments from the State



Version 0.9 of 169 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


Version 0.9 of 169 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


Version 0.9 of 169 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


Version 0.9 of 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


Version 0.9 of 169 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


Version 0.9 of 169 03/10/2021

Figure 26. One Washington Continuous Improvement Process ............................................................................ 168


Version 0.9 of 169 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.


Version 0.9 of 169 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


Version 0.9 of 169 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 Lead

In accordance with methodologies and standards found in Project Management 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 Management (OCM) Lead

Leads the One Washington OCM efforts, directing organizational and stakeholder 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.


Version 0.9 of 169 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 development of business process and role design documents, reviews impact assessment, and assists in the identification of gaps.

Responsible for overall management of the Financials functional team and for the coordination of their work with the work of other team members/leaders.

Completes hands-on functional and technical project activities and provides 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 completion of deliverables required by the Project Work Plan.

Oversees the overall design, testing and deployment of the technical areas.


Version 0.9 of 169 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 completion of 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.

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.


Version 0.9 of 169 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 coordination of their work with the work of other team members/leaders.

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 coordination of their work with the work of other team members/leaders.

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 completion of deliverables required by the Project Work Plan.



Version 0.9 of 169 03/10/2021


Completes hands-on functional and technical project activities and provides 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 completion of deliverables required by the Project Work Plan.


Completes hands-on functional and technical project activities and provides 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).


Version 0.9 of 169 03/10/2021

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


Version 0.9 of 169 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


Version 0.9 of 169 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:


Version 0.9 of 169 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.


Version 0.9 of 169 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.


Version 0.9 of 169 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.


Version 0.9 of 169 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 Workstream Teams and Team Leads

Escalation 0: Team Members escalate RAID items to their respective Workstream Lead (e.g., Finance, HCM, OCM, etc.) through regular, day-to-day interactions. Escalation level in PMC for RAID items is left blank.

Project controls will be escalated to the Workstream Lead when:

The RAID item impacts the workstream only and does not require input or involvement from other workstreams

The CR impacts the workstream only and does not impact the Phase 1A scope, schedule or budget

One Washington PMO

Escalation 1: Workstream leads escalate RAID items to the PMO by changing the escalation level in PMC to 1, or submit CR to PMO for discussion in next status meeting, or schedule a meeting if urgent and status meeting is more than 2 days away.

RAID items and CRs will be escalated to the PMO when:

The RAID item cannot be resolved by Workstream Teams, and the RAID priority is 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 Committees

Escalation 2: PMO Manager escalates RAID item to the appropriate Advisory Committee(s) by changing the escalation level in PMC to 2, or sharing CR and setting up a meeting with proper participants to discuss within two working (2) days of escalation, with aim of resolving item in 4-5 working days.

RAID items and CRs will be escalated to the Advisory Committees when:

The RAID item cannot be resolved by PMO working with the appropriate Workstream Team Leads, and the RAID priority is not Low

The CR will impact Phase 1A scope, schedule or budget < 7.5%

Business Transformation Board (BTB)

Escalation 3: The Advisory Committee Chair(s), will determine when RAID items or CRs need to be escalated to the BTB; and when escalated, will receive process support from the PMO. To escalate a RAID item or CR to the BTB, the PMO will work under the direction of 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

RAID items and CRs will be escalated to the BTB when:

The RAID item cannot be resolved by PMO working with the appropriate Advisory Committees, and the RAID priority is not Low

The CR will impact Phase 1A scope, schedule or budget < 10%


Version 0.9 of 169 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 Steering Committee (ESC)

Escalation 4: The BTB Program Director, in conjunction with the PMO Manager and any impacted Advisory Committee Chair(s), will determine when RAID items or CRs need to be escalated to the ESC. To escalate a RAID item or CR to the ESC, the PMO will:



3. Send the RAID item or CR with 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

RAID items and CRs will be escalated to the ESC when:

The RAID item cannot be resolved by PMO working with the BTB and appropriate Advisory Committees, and the RAID priority is not Low

The CR will impact Phase 1A scope, schedule or budget > 10%

Executive Sponsor

Escalation 5: The ESC Executive Director, in conjunction with the PMO Manager, BTB Program Director and any impacted Advisory Committee Chair(s), will determine when RAID items or CRs need to be escalated to the Executive Sponsor.

To escalate a RAID item or CR to the Executive Sponsor, the PMO will:



3. Send the RAID item or CR with 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

RAID items and CRs will be escalated to the ESC when:

The RAID item cannot be resolved by PMO working with the ESC, BTB and appropriate Advisory Committees, and the RAID priority is not Low

The CR will impact Phase 1A scope, schedule or budget > 10%


Version 0.9 of 169 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.


Version 0.9 of 169 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


Version 0.9 of 169 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 Responsibilities

Chairs the ESC Resolves items escalated by ESC or executive director Oversees the circuit-breaker process

Performance and Oversight Controls

Regular briefings by executive director Monthly ESC meetings including program performance measures 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-officio Members

See the One Washington Governance Membership Chart

Membership selection

Members are appointed by the executive sponsor. The executive sponsor has full authority to appoint and remove members to ensure the success of the program.

Additional ESC Meeting Participants

OCIO oversight partners External quality assurance (QA) consultants 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.


Version 0.9 of 169 03/10/2021

Decision-making process

1. Discussion of the recommendations put forward by the One Washington 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.


Actively participate in ESC meetings 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


Monthly executive director’s ESC briefing including program performance measures

Monthly reports from quality assurance consultant Recommendations from the Office of the Chief Information Officer

Stakeholder communication responsibility

Agency leaders are expected to involve and inform all relevant parties in their agencies and/or the agencies they represent.

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


Version 0.9 of 169 03/10/2021

Membership selection

Make-up: 10-15 members total; membership will be diverse in agency size, 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 Participants

External quality assurance (QA) consultant 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.


Version 0.9 of 169 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


1. Discussion of the recommendations put forward by the One Washington program or 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.


Promote continuous alignment of the program’s strategic objectives, timelines, 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


Version 0.9 of 169 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


Monthly program director’s BTB briefing, including program performance measures

Monthly reports from quality assurance Recommendations from the Office of the Chief Information Officer


Business owners are expected to involve other sub-business owners: e.g., HR may include leaders of HCA, DRS and DES, as needed

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.


Version 0.9 of 169 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


1. Discussion of the recommendations put forward by the chairperson, the One 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.


Version 0.9 of 169 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.


Vet issues, analyze business priorities and propose enterprise-level 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


Chairperson is responsible for ensuring documentation of the meetings (this can be delegated) that includes:

Attendees Agenda Highlights and decisions


Version 0.9 of 169 03/10/2021

Action items with dates and leads

Meeting notes and decisions will be stored on the One Washington program SharePoint site.


Involve and inform leaders and subject matter experts for all relevant parties in their respective agencies and/or the agencies they represent as well as agencies who may be 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


Prepare briefings and reports for ESC and BTB meetings 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


Briefings and reports from ESC, BTB and advisory committees PMO reports of performance and quality Feedback from the executive sponsor, executive director, program director, ESC,

BTB and advisory committees Reports from the quality assurance consultant


Communicate with all stakeholders through all branches of State government, including higher education as appropriate.


Version 0.9 of 169 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 Participants

External quality assurance (QA) consultant 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


There is no formal decision-making process: Issues must either go to the BTB or an advisory committee or be handled within the authority of the business owner.


Actively participate and provide information and issues at the ESC 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


Version 0.9 of 169 03/10/2021


Please see the BTB and Advisory Committee details.


Business owners are expected to involved other sub-business owners (e.g., HR may include leaders of HCA, DRS and DES), as needed, as well as agencies who may be impacted.


Version 0.9 of 169 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


Version 0.9 of 169 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.


Version 0.9 of 169 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


Version 0.9 of 169 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


Version 0.9 of 169 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 Coordinator

Manage program-level schedule status information; that is, budget, funding, 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 + Deloitte Program Director

Provide guidance and oversight on the development and management of the project schedule

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


Version 0.9 of 169 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

Addition or deletion of project tasks

No impact to budget, major milestones, critical path or project completion date Project Manager

Impacts major milestones but does not impact critical release budget or project completion date

Business Transformation Board

Impacts release budget, critical path or project completion date Executive Steering Committee

Changes to the completion date of a task





Change to task dependencies





Re-baseline schedule

Provides a mechanism to re-align the schedule to negotiated, revised milestones or to address additions/removals of tasks.

Executive Steering Committee

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


Version 0.9 of 169 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.


Version 0.9 of 169 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:


Version 0.9 of 169 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 (Release)

Plan 1A <Name>

1 Stage Plan, Architect, Configure and Prototype, Test, Deployment, Sustainment

X

2 Workstream Project Management, Functional, Architecture and Security, etc.

X.XX

3 Activity Collection of related tasks to get something done

X.XX.11111

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 Level Task Notes

Task Resources Names

Update Source

Predecessor (Task ID)

Task Duration

Start Date

Finish Date

0 Project Summary Summary task for Phase 1B

N/A N/A No Project Total Duration

Project Start Date

Phase 1A End Date

1 Project Stage Plan, Architect, Configure and Prototype, Test, Deployment, Sustainment

N/A -N/A No Calculated based on sum of task durations

Calculated based on predecessors of tasks

Calculated based on first task start plus the cumulative duration of subsequent tasks

1.1 Workstream Project Management, Functional, Architecture and Security, etc.

-N/A No Calculated based on sum of task durations



1.1.1 Activity Collection of tasks that results in an output, e.g., work product, deliverable, milestone event

- N/A No Calculated based on sum of task durations




Version 0.9 of 169 03/10/2021

Work Breakdown Structure (WBS) Dictionary

WBS Level Task Notes

Task Resources Names

Update Source

Predecessor (Task ID)

Task Duration

Start Date

Finish Date

1.1.1.1 Task Lowest level of decomposition: a discrete Step/Task, Deliverable, Milestone, Dependency

One or more Last Name of the lead on the task; no names needed for work products, deliverables, milestones

One or more Last Name of associated Workstream Lead

Yes Entered manually

Calculated based on predecessors of task

Calculated based on task start plus the duration of the task

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


Version 0.9 of 169 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 predecessor activity.

Start-to-Finish (SF): The completion of the successor activity depends upon the initiation of the predecessor activity.

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.


Version 0.9 of 169 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.


Version 0.9 of 169 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.


Version 0.9 of 169 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 (%) Complete

The % Complete field contains the current status of a task, expressed as the percentage of the task's duration that has been completed.

Team The Team name of the resource(s) responsible for a task.

Resource Names

The Resource Name field contains the name of an individual(s) responsible for a task.

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


Version 0.9 of 169 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.


Version 0.9 of 169 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.


Version 0.9 of 169 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 Step

Description Responsible Timing

Publish Assignments The updated project schedule for the next week is available to all project team members.

Deloitte Project Manager Friday

Track Progress Deloitte Project Manager and Scheduler solicit task updates from 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.

Accountable/responsible Team Leads

Thursday by 1 pm PT

Analyze Progress and Performance

The task progress tracking is reviewed to determine the impact upon the project schedule;

Deloitte Project Manager PMO Manager

Friday


Version 0.9 of 169 03/10/2021

findings to be reported at Monday PMO Stand-up Meeting.

Re-plan Project leadership adjusts the Work Plan (if necessary) in light of changing circumstances, through the use of a change request.

Deloitte Project Manager PMO Manager Team Leads

As needed

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.


Version 0.9 of 169 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


Version 0.9 of 169 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:


Version 0.9 of 169 03/10/2021

Table 16. Quality Performance Metrics

Metric Calculation Method Target Percent of critical path tasks and milestones completed on time

# of milestones completed late / # milestones (%)

<10%

Number of schedule changes that cause a change to milestone completion date or Go-Live date

# of changes / # of milestones <10%


Version 0.9 of 169 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.


Version 0.9 of 169 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

Roles Responsibilities One Washington Budget Manager

Develop, oversee and report on budget 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 Analysts (If funded)

Help manage funding/reporting for the Agency OCM pool and One Washington technology pool

Conduct bill analysis-during legislative sessions, review bills that may impact One Washington and identify/quantify any impacts

One Washington Business Operations Manager

Support the Budget Manager in developing the budget, and oversee the change control and deliverable review processes

Work with appropriate resource managers and HR representatives for program staffing

One Washington Program Director

Verifies that deliverables are complete before an invoice is approved

One Washington Executive Director

Approves changes, from the currently approved technology budget, to the finally submitted budget

One Washington Executive Sponsor

Approves all budget changes of more than 10% of project total, phase total, biennium total, FY total, gate total

One Washington Project Management Office

Oversees the development and quality of for the deliverables 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


Version 0.9 of 169 03/10/2021

Roles Responsibilities Helps with OCIO-Gated Funding process and legislative staff

engagements

Office of the Chief Information Officer

Oversees the Gated Funding process that One Washington must follow

One Washington Contract Managers

Review contractor invoices by the appropriate state staff, 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 Executive Steering Committee


One Washington Business Transformation Board


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


Version 0.9 of 169 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.


Version 0.9 of 169 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


Version 0.9 of 169 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


Version 0.9 of 169 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.


Version 0.9 of 169 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 Status Report

The current Fiscal Year total project budget versus spend (cumulative totals by month)

Monthly

One Washington Performance Quality Metrics

Percent variance between forecasted expenditures and actual expenditures

Monthly

One Washington Fiscal Reports (Legislative Staff)

Enterprise Reporting- by vendor and allotment expenditure revenue status flexible. Web intelligence report-expenditure details, by fiscal month, by object and vendor.

Monthly

One Washington Quarterly Report to Legislative Fiscal Committees

Report includes: expenditures for the quarter, projected expenditures for the next quarter, contractor FTE equivalent, deliverables-completed and projected.

Quarterly

One Washington Financial Status Report

Report includes: current expenditures FYTD, projected expenditures for the biennium, assumptions, areas of concern, etc.

Monthly

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;


Version 0.9 of 169 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.


Version 0.9 of 169 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.


Version 0.9 of 169 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.


Version 0.9 of 169 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


Version 0.9 of 169 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.


Version 0.9 of 169 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


Version 0.9 of 169 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


Version 0.9 of 169 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.


Version 0.9 of 169 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

Roles Responsibilities All One Washington project team members

Identify and log One Washington RAID items into PMC as they are 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


Version 0.9 of 169 03/10/2021

Roles Responsibilities 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)


Advise and provide recommendations for risk mitigations, 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 Director

Ensure accountability of all roles within the RAID management process 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


Version 0.9 of 169 03/10/2021

Roles Responsibilities Executive Steering Committee (ESC)

Advise and provide recommendations for escalated RAID items to the 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 Executive Director

Advise and provide direction to the ESC and BTB, as required 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


Version 0.9 of 169 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:

Legend

StepSupporting

Output DecisionTask ProcedureInputs / Outputs

1. Identify and Analyze Risk

Project Management

Plan

2. Is Risk Severity High?

Yes 3. Develop Risk Response

4. Monitor Risk 5. Is the Risk Realized?

Yes 6. Manage Issues

7. Is the Risk Active?

8. Close RiskNoYes

Risks Log

No

No

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:


Version 0.9 of 169 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


Version 0.9 of 169 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


Version 0.9 of 169 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).


Version 0.9 of 169 03/10/2021

Risk Type Risk Type Description Project Management

Any risk related to the management of the project (such as communications, status reporting, 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)


Version 0.9 of 169 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.


Version 0.9 of 169 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:

1. Create Action Item

2. Perform Action Item

4. Close Action Item

Legend

StepSupporting


Project Management

Plan

Yes3. Action Item Ready to Close?

Action Items Log

No

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.


Version 0.9 of 169 03/10/2021

6.4.1 Issue Process Summary

The flowchart below summarizes the issue management process/workflow followed in PMC:

1. Create Issue 2. Resolve Issue

Legend

StepSupporting


Project Management

Plan

3. Change Request?

5. Close Issue

4. Manage Change

RequestsYes

No

Issues Log

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.


Version 0.9 of 169 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.


Version 0.9 of 169 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 Management

Any issue related to the management of the project (such as communications, status 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.


Version 0.9 of 169 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


Version 0.9 of 169 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:

1. Identify and Document Decision

Project Management

Plan

2. Formal Decision

Required?Yes 3. Perform

Formal Decision

Legend

StepSupporting


5. Make Recommendations

4. Assess Alternatives

6. Proposed Recommendation

Approved ?

Decisions Log

No

Yes7. Communicate and Implement

Decision

No

Figure 19. One Washington Decision Process


Version 0.9 of 169 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.


Version 0.9 of 169 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 Roadmap and Release Strategy

ESC, Program Directors, Budget Manager, Advisory Committee Chairs, PMO managers

2 Foundational Data Model (FDM) Strategy and Approach

ESC, Program Directors, Budget Manager, Advisory Committee Chairs, PMO managers

3 One Company versus Agency Process

Program Directors, BTB, relevant Advisory Committee members, PMO managers

4 Tool selection Program Directors, Budget Manager, Chief Technology Officer, PMO managers, workstream/team lead(s)

5 Key architectural decisions with multiple options

Program Directors, Budget Manager, Chief Technology Officer, PMO 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.


Version 0.9 of 169 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.


Version 0.9 of 169 03/10/2021

Figure 20. One Washington Prioritization Matrix for Project Decisions


Version 0.9 of 169 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 Management

Any decision related to the management of the project (such as communications, status 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.


Version 0.9 of 169 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.


Version 0.9 of 169 03/10/2021

Risk and issue management approach

The process of risk management that includes identifying, analyzing and addressing risks in order to mitigate their negative effects on a project.

Issue priority The importance of the issue severity, ranked low, medium or high.

Risk response strategy

The process of developing strategic options, and determining actions, to reduce threats to the 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].”


Version 0.9 of 169 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.


Version 0.9 of 169 03/10/2021

Table 28. Change Control Roles and Responsibilities

Roles Responsibilities Executive Sponsor Provides approval or rejection of all escalated CRs from the ESC

Executive Steering Committee (ESC)

Reviews CRs and validates viability, estimates, and evaluations

Works with PMO to determine whether CR should be approved, deferred, rejected, or escalated to Executive Sponsor


Reviews CRs and validates viability, estimates, and evaluations

Works with PMO to determine whether CR should be approved, deferred, 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

Works with PMO to determine whether CR should be approved, deferred, rejected, or escalated to BTB; and if so, provides CR recommendation

Project Management Office (PMO)

Reviews CRs and determines viability, estimates, and evaluations

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 )


Version 0.9 of 169 03/10/2021

Roles Responsibilities 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.

Thumser-Kerlee, Julie (OFM)


Version 0.9 of 169 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


Version 0.9 of 169 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.


Version 0.9 of 169 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.


Version 0.9 of 169 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


Version 0.9 of 169 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.


Version 0.9 of 169 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:


Version 0.9 of 169 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

Roles 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


Version 0.9 of 169 03/10/2021

Roles Responsibilities State Workstream Leads

Identifies participants for PDD workshop prep, production and follow-up

Oversees content development needed for PDD workshops and reviews

Deloitte Workstream Lead

Confirms and manages scope of PDD workshops

Supports the project vision and direction during the PDD workshops

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 Analyst

Organizes PDD workshops and manages logistics for PDD Prep, PDD workshops and 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 Washington SMEs and Business Owners

Provide subject matter expertise during the One Washington Discovery and Design working sessions and reviews

Provide guidance on state of Washington standard operating policies, procedures, and compliance items

Provide direction on One Washington vision, objectives, and priorities

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.


Version 0.9 of 169 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 RequirementsUser StoriesConfiguration WorkbooksIntegration Designs Test Cases is up-to-date, accurate, and maintained.


Version 0.9 of 169 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

Roles 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


Version 0.9 of 169 03/10/2021

Roles Responsibilities

Workstream Leads

Direct design/configuration review meetings

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 Team

Provide estimates for configuration of features and functionality

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 Business Owners

Provide and confirm integration design requirements

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


Version 0.9 of 169 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.


Version 0.9 of 169 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

Activity Milestone/Deliverable Deloitte Responsibility

One Washington Responsibility

Complete Workday Security training

Deliverable: Project Team Workday Training Plan and Training

Support Primary

Create Solution Architecture

Deliverable: Solution Architecture Primary Support

Create and define Configuration Security Framework

Deliverable: Configuration Security Framework

Primary Support

Develop mobile usage deployment requirements

Deliverable: Mobile Usage Deployment Requirements

Primary Support

Conduct authentication design sessions

N/A Primary Support

Update SAW authentication components as required to support the Workday implementation

N/A Support Primary


Version 0.9 of 169 03/10/2021

Activity Milestone/Deliverable Deloitte Responsibility

One Washington Responsibility

Configure authentication process in Workday tenant

Milestone: Configuration 1 Tenant Build Primary Support

Test authorization authentication process in Workday tenant


Conduct Discovery and Design Sessions

Deliverable: Configuration Security Framework

Primary Support

Conduct Integration Design Sessions

Deliverable: Integration Design Primary Support

Conduct Integration Design Sessions – State

Deliverable: Integration Design – State Support Primary

Configure role-based security and unit test


Review roles-based security

Milestone: Customer Confirmation Sessions Primary Support

Test role-based security Deliverable: End-to-End Test Results Support Primary

Configure integration security and unit test - Contractor

Deliverable: Integrations Developed and Unit Test - Contractor

Primary Support

Configure integration security and unit test – State with support from Contractor

Deliverable: Integrations Developed and Unit Test - State

Support Primary

Test Integration security Deliverable: End-to-End Test Results Support Primary


Version 0.9 of 169 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


Version 0.9 of 169 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


Version 0.9 of 169 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 ([email protected]). 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


Version 0.9 of 169 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.


Version 0.9 of 169 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.


Version 0.9 of 169 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 documents

<OneWa-###DEL-Deliverable Name>.<File Extension>

Example: OneWa-001DEL-Project Kick-off Session.pptx

3 Project work product documents

<OneWa-Work Product Name>.<File Extension>

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


Version 0.9 of 169 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 ([email protected]).

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...>


Version 0.9 of 169 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 may trigger updates to this plan include:

Review of the resource requirements by the ERP procurement assistance consultant, ERP expert 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 the direction 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:


Version 0.9 of 169 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 the project 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 Description

Key Responsibilities

Executive Director This role provides leadership and guidance for the program. Acts as an “owner” and champion of the program in support of meeting the executive sponsor and executive steering

Define program vision, goals and objectives

Approve program budget and changes


Version 0.9 of 169 03/10/2021



committee’s expectations. The executive director has strategic and tactical plan execution responsibility, which includes scope, schedule, budget and quality. The executive director reports to the executive sponsor.

Approve program change requests to baseline (i.e., scope, resources and budget)

Communicate program goals, objectives, and priorities

Approve solution vendor contract

Approve, review, monitor and report program metrics

Resolve issues that could not be 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


Version 0.9 of 169 03/10/2021



Program Director This role directs program activities, provides operational and tactical direction to the program teams to assist in identifying proper level/forum for where key decisions are made, assists with alignment of resources, framing/boundaries for scope and advice on project budget. The program director reports to the executive director.

Accountable for overall execution, management and delivery of the program’s: scope, schedule, budget and sustained operations

Provide leadership to program functional team leaders/managers

Approve and monitor all 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


Version 0.9 of 169 03/10/2021



Chief Technology Officer (CTO)

This role is responsible for providing sound technical leadership in all aspects of the One Washington program and providing technical leadership for the implementation of the ERP solution. The chief technology officer reports to the program director.

Develop and execute the One Washington technology architecture and strategy

Ensure the technology architecture and strategy are compatible with the selected ERP vendor’s technology 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 technical guidance in all aspects of the One Washington program and providing technical leadership for the implementation of the ERP solution. The technical lead reports to the chief technology officer.

Single point of authority and technical responsibility for statewide ERP solution

Provide leadership, mentoring and leads technical teams in executing project deliverables

Establish priorities for 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


Version 0.9 of 169 03/10/2021



Senior IT Architect This role serves as the expert on all technical work streams throughout the program. This role will analyze technical processes, determine specifications and communicate needs clearly to program leadership. This position will be responsible for all aspects of the technical specifications gathering activities as well as the technical aspects of the system implementation including networking, cyber security, access, identity management, cloud platform delivery, high level approach to system integration and future state as well as business continuity in the design. The senior IT architect reports to the chief technology officer.

Lead/manage solution design, development and implementation for mission critical, high visibility systems within the One Washington program and supporting other state agencies

Ensure public-facing internet applications follow established usability guidelines, architectural standards and security practices

Develop new and innovative enterprise level information solutions in support of One Washington

Develop conceptual and logical artifacts so application capabilities are aligned to business outcomes

Data and Business Intelligence Manager

This role leads the development of data governance and implementation strategy and execution for One Washington data and business intelligence solutions. The data and business intelligence manager reports to the chief technology officer.

Develop overall data and business intelligence strategy and framework

Facilitate the data governance advisory committee to establish One Washington’s 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


Version 0.9 of 169 03/10/2021



Business Analyst This role leads the development of data governance and implementation strategy and execution for One Washington data and business intelligence solutions. The business analyst reports to the chief technology officer.

Translates business requirements into ERP solutions

Perform business systems and workflow analysis, and disseminates technical communications

Support and maintain related ERP systems and processes to meet business requirements

Perform as subject matter expert for ERP business related systems


Version 0.9 of 169 03/10/2021



Organizational Change Management Director

This role supports the mission of One Washington by leading and promoting the successful transformation of the state’s employees, its stakeholders and their systems and processes, and the state’s core business functions in preparation for the implementation of new integrated systems. The organizational change management director reports to the executive director.

Provide organizational development and change management leadership

Accountable for overall OCM communication strategy and plans

Support organizational change management communication requirements

Participate in the development of 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 Consultant

This role participates in the development of stakeholder assessments and communications plans and executes those plans under the direction of the organizational change management director. The communications consultant reports to the OCM director.

Participate in the development and updates to the One Washington communications plan draft communications

Draft surveys and manages survey data

Maintain stakeholder lists Maintain the program e-mail

box, website, and style guide, etc.


Version 0.9 of 169 03/10/2021



Project Management Office Manager

This role manages the tactical activities of the program, including the activities of the four core projects (finance, procurement, budget and HR/payroll) and the activities of the PMO staff. The project management office manager reports to the program director.

Accountable for execution of tactical activities for the four core projects

Ensure integrated program schedule is maintained –

provide regular reports Manage the PMO staff activities

in support of the core projects 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


Version 0.9 of 169 03/10/2021



Project Managers These roles will support the transformation of enterprise administrative/business systems and implementation of information technology solutions by leading/managing enterprise IT projects and delivering results using proven project management methodology. The project manager positions report to the project management office manager.

Work with stakeholders and business owners in defining project scope, budget, schedules and deliverables

Develop project work plans identifying all tasks necessary to complete project work streams

Organize project work plans in a logical and efficient order

Conduct risk assessments and identifies critical issues, mitigation strategies and escalates as appropriate

Reprioritize and adjust work plans for changing conditions or new information

Develop reports on recurring and ad-hoc basis

Manage business areas and technical activities


Version 0.9 of 169 03/10/2021



Project Coordinator This role is responsible for performing functions in support of project managers and will have specific duties and responsibilities assigned to them by the PMO manager. The project coordinator reports to the PMO manager.

Maintain project management processes and plans

Maintain integrated project schedule

Facilitate use of project management processes in 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 Area Leads (Finance, Procurement, Budget, HR and Payroll)

These roles serve as One Washington's lead subject matter experts on state enterprise business process and systems (finance, procurement, budget, HR and payroll); supporting the ongoing use and development of the state's new ERP system. Additionally, they work to transform business operations and solve business problems by analyzing business processes, determining business needs and communicating clearly to stakeholders, technology developers, and vendors. The business functional leads report to the PMO manager.

Facilitate and lead the work and stakeholder sessions with business stakeholders to identify and document enterprise business capabilities, business outcomes and user stories, to understand and define business processes, policies and application specifications

Produce project documentation such as use cases, business rules, functional requirements, and non-functional requirements

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 direction to ensure program efforts are aligned with program goals, and objectives are met timely with quality work products

Assist with future business line training endeavors


Version 0.9 of 169 03/10/2021



Business Functional Area Subject Matter Experts – Specialists (Finance, Procurement, Budget, HR and Payroll)

These roles provide subject matter expertise and support across business functional aspects of their respective business lines. They are involved in activities such as business capabilities definition, use case and user story development, business process analysis and redesign. The business functional area subject matter experts report to their respective business functional lead.

Facilitate and lead the work and stakeholder sessions with respective business stakeholders to identify and document enterprise business capabilities, business outcomes and user stories, to understand and define business processes, policies and application specifications for One Washington software selection

Produce project documentation such as use cases, business rules, functional requirements, and non-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


Version 0.9 of 169 03/10/2021



Enterprise Senior Consultant

This role supports the mission of One Washington by running day-to-day management of specific projects. Additionally, they will produce specific deliverables (such as procedures and/or KPIs methodologies) for monitoring organizational performance and mediating issues with program or enterprise-wide impact. The enterprise senior consultant reports to the business operations manager.

Facilitate meetings to gather status information, resolve issues, or facilitate team interaction

Implement change control processes

Communicate project changes to project stakeholders

Perform risk assessment activities across subordinate projects, including risk identification, mitigation, 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 Manager

This role is responsible for ensuring the program’s core business functions are performed including budget management, HR management, facilities management and contracts management. Additionally, this role provides team organizational development opportunities. The business operations manager reports to the executive director.

Manage program staffing and resources

Provide vendor contract oversight for deliverables, management and creation

Establish business processes and procedures (HR, budget, contracts, facilities, etc.)

Ensure business processes are 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


Version 0.9 of 169 03/10/2021



Budget Manager This role is responsible for creation of budget documents, tracking expenditures, reporting status against budget and representing the budget to stakeholders. The budget manager reports to the business operations manager.

Create budget documents in support of decision packages, gated funding process and investment plans

Track program expenditures Monitor and report actual and

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 Analyst

This role supports the mission of One Washington by serving as a consultant to executive management, leading the programs continuous process improvement efforts, and by providing operational support to all levels of the program. The management analyst reports to the business operations manager.

Identify, recommend, and implement ways to increase program operational efficiencies

Develop and/or report out on fundamental business operations

Plan, create, implement and execute maintenance on standardized tools and business processes

Develop executive-level documents, program presentations, meeting minutes, agendas, memos, and status reports

Direct SharePoint administration and maintenance for a complex multi-network SharePoint environment


Version 0.9 of 169 03/10/2021



Executive Assistant This role serves as the program's correspondence coordinator and is responsible for managing incoming and outgoing correspondence for the executive director, which includes drafting, editing, and finalizing a variety of executive-level documents for signature. Additionally, the executive assistant provides support to other program senior leaders. The executive assistant reports to the executive director.

Manage calendar appointments and scheduling for the executive director and program director

Provide administrative support to executive director on legislative matters, which includes managing calendar, scheduling meetings, and monitoring emails

Execute administrative functions and assist with day- to-day operations/functions

Assist with the logistics and scheduling of stakeholder meetings, workshops and events

Business Owners These roles serve as the lead for the functional areas of finance, procurement, budget, HR and payroll. Business owners will define and champion the implementation of business process needs and requirements related to their respective areas. This effort will be in collaboration with program staff, advisory committees and the business transformation board. The business owners provide updates to the program director and do not report directly to program staff.

Collaborates with OneWa and its associated governing bodies to identify business process areas for improvement

Reports status to the program director and the business transformation board

Assess and decide software and system integrator that best fits their functional areas

Review and provide feedback on SI request for proposal

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

Version: 0.9 03/10/2021


of 169

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 03/10/2021


of 169

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 And Advisory Services**

Dan Ward and Liz Colon Integrated Solutions Group

Organizational Change Management Services** Jennifer Rocks and team Deloitte ERP Procurement Assistance Consulting Services**

Robin Milne and team Plante Moran

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.

Version: 0.9 03/10/2021


of 169

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

Version: 0.9 03/10/2021


of 169

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 and quality

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

Version: 0.9 03/10/2021


of 169

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 SharePoint site.

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 and may 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

Version: 0.9 03/10/2021


of 169

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.

Version: 0.9 03/10/2021


of 169

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 Delivery

Approach

Project Phase Needed

1 Project Management Center (PMC) usage (RAID)

Project team Virtual Class/Demo

Imagine/Plan

2 OFM-OneWa SharePoint and Microsoft Teams

Project team Virtual Class/Demo

Imagine/Plan

3 Workday Demo Project Team Virtual Class/Demo

Imagine/Plan

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.

Version: 0.9 03/10/2021


of 169

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 PMOOnboarding 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 PMOOffboarding folder for more information: <provide link>

11.2.9 Resource Project Compliance

<What should be addressed here?>

Version: 0.9 03/10/2021


of 169

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.


of 169

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-Contacts (POCs)

Purpose and Usage Access Data Handling Left Behind

Hoover Deloitte Finance Team – Individual TBD State: Mistyjean Brown and Dan Ward

Hoover for Workday is a proprietary data upload utility that can be used to support the conversion process beyond Informatica, automating the loading of templates and perform validation on the converted data. It allows us to iteratively refine the translation and conversion process through successive conversions and to drive to a more rapid and predictable conversion event with production data at Go-Live.

Installed on State VM. Access to the VM is controlled by State and can be restricted to the State laptops used by the Contractor Project team. Hoover will access OFM Records and Data on an sFTP site, perform the appropriate conversion activities and move the data to Workday. This requires a point-to-point connection to the Workday tenant to be loaded. Access is to Deloitte only.

OFM Records and Data is stored in the Hoover data store on the State VM. Access to State sFTP server to pick up data and to store status/error reports on conversion.

No

Rover Deloitte Finance Team – Individual TBD State: Mistyjean Brown and Dan Ward

Rover is Deloitte’s propriety, automated pre-conversion data validation tool. Deloitte manages this tool with inputs from the State to ease data validation efforts after conversion.

Installed on State Virtual Machine (VM). Access to the VM is controlled by State and can be restricted to the State laptops used by the Deloitte project team. Rover will access OFM Records and Data on an sFTP site, perform the appropriate conversion activities and move the data to Workday. State and Deloitte will utilize this tool.

OFM Records and Data is stored in the Rover data store on the State VM.

No

CompareEdge

Deloitte Finance Team – Individual TBD

Proprietary tool that accelerates the comparison of large volumes of data, used extensively for payroll compare test Provides variety of reporting capabilities to quickly identify root cause of discrepancies

Access is for Deloitte team only Java based application hosted on AWS-Cloud Platform Utilizes Web Application Firewall which prevents applicational layer attacks such as,

Data at rest is encrypted using Advanced Encryption Standard in Galois/Counter Mode (AES_GCM) with 256 bit secret keys and data in transit (HTTPS 443) is encrypted using TLS 1.2 or above

No


of 169



State: Mistyjean Brown and Dan Ward

One Washington Payroll legacy payroll data and One Washington Workday payroll data are loaded into CompareEdge. CompareEdge compares the data providing reports on discrepancies. Reports are then downloaded to the sFTP for analysis by the One Washington project team.

cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection

Minimal personally identifiable information (PII) is stored in CompareEdge: employee ID numbers and pay amounts Once a project is completed, data and reports in the tool can be downloaded archival purposes and then securely and completely purged from the system.

ThinkTank™ Deloitte Finance Team – Individual TBD State: Mistyjean Brown and Dan Ward

ThinkTank is a collaboration tool that supports objective definition, requirements collection, design, implementation review by creating an open and structure online forum for project and program success.

Web based third-party tool with access provided by Deloitte team. State team access is provided by the Deloitte team.

Deloitte team to utilize State-provided machines for access.

Discussion topics like business process detail is presented through in the tool. Survey data, questions and parking lot logs can be captured in tool and exported to issue tracking tools for resolution and use in design. Downloads on State machines and moved to State servers

No

Project Management Center (PMC)

Deloitte PMO – Individual TBD State: Mistyjean Brown and Dan Ward

Our standard project management information system (PMIS) for managing risks, action items, issues, and decisions (RAID) items for an implementation project within the PMO. Based upon the MicroFocus Project and 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.

Web based tool hosed by Contractor. Access is provided by Contractor and is secured with MFA also. Access is for the State and Deloitte project teams. and possibly a few Agency SMEs needing access.

No OFM Records and Data will be stored in PMC. One Washington project RAID items.

No

ALM - Octane

Deloitte Finance Team – Individual TBD State: Mistyjean Brown and Dan Ward

Octane is a cloud-based application lifecycle management (ALM) platform that will enable the One Washington workstreams to collaborate on configuration, integration development, reporting and other project tasks. Octane will also be used to plan, execute and manage all Workday testing activities.

Web-based tool hosed by Deloitte. Access is provided by Deloitte and secured with MFA also. Access is for the State project team and Agency key users involved in testing activities.

No OFM Records and Data is stored in Octane. ** As part of a user story/test case, an employee ID or some other reference may be made to OFM Records and Data.

No


of 169



AccordGrid Deloitte Finance Team – Individual TBD State: Mistyjean Brown and Dan Ward

AccordGrid plots the value and effort across a set of reporting requirements and visually displays the results in a quadrant view that enables quick and decisive planning. AccordGrid can help measure the effort and value involved with a given requirement. The use case is to prioritize the list of reports needing to be built and identifying Deloitte versus State team for implementation.

Excel spreadsheet add in. No confidential OFM Records and Data will be used or impacted.

Yes*

*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 Toolset

Software and license rights for designated Deloitte personnel to use Basecamp and


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 Toolset

Software and license rights for designated Deloitte personnel to use Basecamp and Microsoft Teams and the data conversion and developers’ tools.

Windows Virtual Machines and Applicable Software

Deloitte Hoover conversion toolset requires installation within the State’s network. Windows Virtual Machines are required for this installation.

Automation Anywhere

Deloitte’s Workday BOTs require this software to be running in the State’s environment to utilize.

Articulate Storyline 360

Tool to support the creation of learning content.

InformaticaTM Server and access are provided by State for use on State-provided laptops.

Implementation BOTs

Proprietary repository of Workday 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.

Version: 0.9 03/10/2021


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)

Version: 0.9 03/10/2021


of 169

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

Week 1

Weekly Workstream Meetings

Weekly PMO Meeting 2-2:45 PM PT

Week 2



Executive Steering Committee Meeting

RAID Status Meeting 2-3 PM PT

Week 3



Business Transformation Board Meeting

Week 4



RAID Status Meeting 2-3 PM PT

Week 5 (where

applicable)



Executive Steering Committee Meeting

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.

Version: 0.9 03/10/2021


of 169

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

# Communication Description Audience Frequency Chairperson/ Responsibility of

1 Project Status Meeting Regularly scheduled meeting to update project leadership on project progress and status. Information presented: Schedule performance Milestone progress Deliverable status RAID items that need attention

Program Director PMO Leads Team Leads

Weekly (Tuesdays), through project closure

Deloitte Project Manager

Version: 0.9 03/10/2021


of 169

# Communication Description Audience Frequency Chairperson/ Responsibility of

CR updates 2 Project Status

Distributions Distribute standard status report after the weekly status meeting, and/or post in the appropriate folder on the SharePoint site

Project leadership Team Leads

Weekly PMO

3 Project Phase Kick-off Meetings

Formal kick-off of next project stage

All project team members

TBD PMO with 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

Roles 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

Version: 0.9 03/10/2021


of 169

Roles Responsibilities 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

Version: 0.9 03/10/2021


of 169

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

Version: 0.9 03/10/2021


of 169

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

Version: 0.9 03/10/2021


of 169

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 Assurance

Quality Control

Definition A set of activities for ensuring quality in the processes by which products are developed.

A set of activities for ensuring quality in

products. The activities focus on identifying defects in the actual products produced.

Focus PROACTIVE REACTIVE

Version: 0.9 03/10/2021


of 169

Considerations Establish a good quality management system and the assessment of its adequacy.

Perform periodic conformance audits of the operations of the system.

Prevention of quality problems through planned and systematic activities including documentation.

Initiate corrective or preventive action as a result of the audit.

Finding and eliminating sources of quality problems through tools and processes such that customer requirements are continually met.

The activities or techniques used to achieve and maintain the product quality, process and service.

Defect repair and measurement of quality indicators.

Tools Standards and metric development

Deliverable Expectation Document (DED)

Peer reviews or stakeholdering

Assessment and reporting of metrics

Checklists

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 One Washington 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.

Version: 0.9 03/10/2021


of 169

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

Roles 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 Reviewer

Perform engagement quality reviews Review the findings with the project leadership team Follow up on action items from previous reviews

Workday Delivery Assurance (DA) Reviewer

Plan and perform Workday DA reviews: Plan Stage, Integration, FDM, Authentication, Configuration, Cutover, Operate

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.

Version: 0.9 03/10/2021


of 169

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

Version: 0.9 03/10/2021


of 169

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 planning and

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 IT Dashboard 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:

Version: 0.9 03/10/2021


of 169

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 Review Reviewers Frequency Objectives

1 Initial Quality Review (QR)

Quality Review executive

Within 3 months of project kickoff

Define the project quality review schedule 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 Review schedule


Every 3 months, or at major project milestones

Follow up on all previous concerns and recommendations

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

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 [email protected] 303-312-4105

Version: 0.9 03/10/2021


of 169

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 DefineDevelopReviewApprove Process described in the Figure below:

Version: 0.9 03/10/2021


of 169

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

Version: 0.9 03/10/2021


of 169

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 Attend walk-through 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 Attend walk-through 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 Coordinator

Schedule and attend content development session(s) with vendor and 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, Purpose, Requirements

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

Version: 0.9 03/10/2021


of 169

DED Component Description Assumptions and Risks

Assumptions or risks critical to the development of the deliverable (e.g., 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 Acceptance Timeframes

The schedule for the deliverable production, review and acceptance process


The roles associated with deliverable production, review and acceptance; 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.

Version: 0.9 03/10/2021


of 169

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

Version: 0.9 03/10/2021


of 169

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.

Version: 0.9 03/10/2021


of 169

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:

Version: 0.9 03/10/2021


of 169

What went well What did not go well What needs to change

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.

1. QA/QC Activities

2. Review Current Quality

Processes

3. Perform Root Cause

Analysis

4. Capture Lessons Learned

5. Apply Process

Improvements

Figure 30. One Washington Continuous Improvement Process

Version: 0.9 03/10/2021


of 169

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).

Project Management Playbook ___ - OCIO Dashboard

Documents

Transcript of Project Management Playbook ___ - OCIO Dashboard