ELRB Statement of Work Phase 2.pdf

uca

State of Illinois Educational Labor Relations Board Case Management - Phase 2

Prepared for

State of Illinois Educational Labor Relations Board (ELRB)

Prepared by

Marc Winder, Solution Architect

Date: September 2, 2025

Version: 1.1

Statement of Work

Table of contents Executive Summary 1 Customer desired business objectives 2 Engagement Overview

2.1 General project scope

2.2 Areas out of scope

3 Delivery approach, timeline, and management

3.1 Approach

3.2 Timeline

3.3 Completion and definition of done

3.4 Delivery Management

4 Engagement governance

4.1 Engagement communication

4.2 Risk and issue management

4.3 Business governance

4.4 Change management process

4.5 Escalation path

4.6 Engagement completion

5 Engagement organization

5.1 Organization structure

5.2 Project roles and responsibilities

6 Customer responsibilities and engagement assumptions

6.1 Customer responsibilities

6.2 Engagement assumptions

7 Tools 8 Glossary and definitions

8.1 Abbreviations and terms

8.2 Defect severity

8.3 Defect priority

Microsoft Services: Statement of Work SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 1 of 29

This Statement of Work (SOW) and any exhibits, appendices, schedules, and attachments to it are made pursuant to Work Order GVS1251-487806-627123 and describes the work to be performed (Services) by Microsoft (“us,” “we”) for State of Illinois Educational Labor Relations Board (“Customer,” “you,” “ELRB,” “your”) relating to ELRB Phase 2 (project).

This SOW and the associated Work Order expire 30 days after their publication date, unless signed by both parties or formally extended in writing by Microsoft.

Executive Summary The scope contained in this SOW is intended to complete the remaining items, identified by ELRB that are required to promote the Dynamics 365 case management solution to production so that they can retire their existing, legacy, solution.

1 Customer desired business objectives

The overall objectives of this project are listed in the following table. These are listed for the sole purpose of providing business context for the project and are not statements of scope or accountability. The project scope specified and limited in Section 2.1 and these objectives have been used as the basis for the estimation of effort and timeline of this engagement.

This engagement will leverage an iterative Sure Step 365, fixed capacity approach, which is outlined in detail later in this document. Scope is variable in an iterative, fixed capacity approach. There may be additional objectives not listed in the following list that are delivered, as well as objectives listed that won’t be completed due to prioritization tradeoffs or fixed capacity constraints. When additional capacity or duration of the delivery team is needed to deliver the agreed-upon objectives, the change management process will be used to allow the project to change resource capacity or duration.

Alternatively, ELRB can decide to reduce the objectives / scope to remain within budget.

Description of objectives

1 Using the solution originally configured for Illinois Educational Labor Relation Board (ELRB) started in Phase 1, complete the remaining configuration with the goal of ELRB being able to retire their existing case management system.

2 Complete the data migration of historical case data (transactional) and master (lookup) data from their existing Access DB using the Data Import Wizard.

2 Engagement Overview

This section outlines the work and activities required to accomplish the objectives set forth in this SOW.

This engagement makes use of a capacity-based delivery model. Microsoft will provide ELRB with a delivery team staffed as defined in the Microsoft roles and responsibilities section and the Enterprise

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 2 of 29

Services Work Order (ESWO). The delivery team will follow the Sure Step 365 methodology (described further in this SOW).

Microsoft will collaborate with ELRB to deliver a Microsoft Dynamics 365 solution. The delivery team will work under the direction of the ELRB product owners who will decide on product features from the backlog to be delivered, and will make decisions on the most effective use of Microsoft’s resources made available under this SOW.

The project will address the scope areas outlined in the sections below which can be revised at any time based on direction from ELRB. There might be additional scope not listed in the following sections that might be delivered, as well as scope listed that is prioritized low enough that it might not be delivered due to capacity constraints.

The scope is variable in an iterative, fixed capacity approach. When the resource labor category, capacity, or duration of the delivery team needs to be amended to deliver the agreed-upon backlog items, the change management process will be used to allow the project to change the available resources and capacity. Alternatively, ELRB may decide to adjust scope to remain within budget. This approach allows ELRB to continually adapt the scope and direction of the solution.

The scope areas defined in the sections below are the targeted scope of work to help establish the initial backlog items. The targeted scope does not constitute a fixed scope of work. The staffing and estimations for this project are based on the scope/backlog discovered along with ELRB. There is no guarantee that all scope area requirements will be completed within the contracted fixed capacity. An ongoing governance process will prioritize scope against available capacity, which would enable Microsoft and ELRB to reprioritize, plan and accommodate scope within the available capacity. This governance process might result in a need for increased capacity and fees.

2.1 General project scope

Microsoft will deliver services to support the specified scope areas, contingent upon available capacity.

Solution Components

Description Assumptions

Review the baseline solution

Review the baseline solution against requirements to create backlog

Baseline solution is defined as the solution that was configured during Phase 1.

Update solution Perform required configuration changes

Complete Minor configuration changes:

• Add a new table to store ALJ information to include Forms and Views. Make updates to the Mediation table to include additional Fields, Views and label changes.

• Add one additional Business Rule and one automation

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 3 of 29

Solution Components

Description Assumptions

• Create KPI dashboard for case tracking and completion.

Dashboard should include:

o Cases that are older than 90 days but less than 120 o Cases that are older than 120 days

• Configure Public Act (PA) 103- 0856 Calculated Field

• Updates to ADO are needed to capture all components of the ELRB solution

• Solution import to Production environment

Data Migrations Migrate historical data from the existing Access database

• Phase 2 will focus on migrating the data from the existing Access DB to Dataverse.

• All work from Phase 1 remains unchanged and the environments (dev, test, prod) are as they were left at the end of Phase 1. This helps ensure that the project can pick up where it left off without additional complications or delays.

• ELRB will continue to validate and reconcile their data. The Data Import Wizard will be used to import the data from Access.

• Microsoft will create up to two (2) Duplication Detection Rules and provide ELRB with knowledge transfer to create their own as part of their validation & reconciliation activities.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 4 of 29

Microsoft Dynamics 365 for Customer Engagement

Solution component or general scope item

Description

1 Deployment Online (GCC)

2 Number of instances Single

3 Datacenter North America

4 Clients Web client

5 Languages US English (base)

6 Number of users 12-14

7 Applications Customer Service

Completed Scope from Phase 1 The areas listed below were completed during the work performed in Phase 1 and will be used as the baseline for the remaining work addressed in this SOW.

Completed Scope Assumption

The following entities were created in the Dev and Test environments:

• Affiliation

• Agent Information

• Allegations

• Case Type

• Closure Method

• County

• Investigation Delay Reason

• Mediation

• Region

• Representation

• School

• Unfair Labor Practices

Creation of entities includes creation of the table, fields, data types, min/max limits, data masks, forms, views, relationships, business rules and automations.

The completed Phase 1 work was reviewed and signed off by ELRB prior to final closeout of Phase 1.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 5 of 29

Master data was loaded for the following tables in the Dev and Test environments: Affiliation, Agent Information, Allegations, Case Types, Closure Methods, Counties, Investigation Delay Reason, Regions, and Schools.

Validation from ELRB was not completed prior to the end of Phase 1 and is still required.

Initial data migration of Representation case and Unfair Labor Practice case data is complete in Dev and Test environments.

Validation from ELRB was not completed prior to the end of Phase 1 and is still required.

More time will be needed to transform the data to ensure data integrity (See Section 2.1 General Project Scope).

Software products and technologies The products and technology that are listed in the following table are required for the project. The Customer is responsible for obtaining all identified licenses and products.

Software type Version Required by date Responsibility

1 Microsoft Dynamics 365 for Customer Engagement

Latest Prior to the project Initiation phase start date

Customer

2 Version control software Microsoft Azure DevOps Prior to the Config & Dev -Analysis activity set start date

Customer

3 Documentation tools Microsoft Office 2016 or later

Prior to the project Initiation phase start date

Customer

Environments and installation The environments listed in the following table will be needed to deliver this project. Provisioning responsibility pertains to the provisioning of Microsoft Dynamics 365 in Customer’s Microsoft tenant. Any delays to the project schedule caused by delays in availability of the service are subject to the Change management process described in Section 4.4 of this SOW.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 6 of 29

Environment Location Primary provisioning responsibility

Shadow responsibility

Environment purpose

Ready by

1 Development Cloud Customer Microsoft Base system reference

2 weeks prior to the start of the Config & Dev - Analysis activity set

2 Test Cloud Customer Microsoft Requirements analysis and functional testing

Project start

3 Production Cloud Customer Microsoft Production Project start

Note: The environments listed above are assumed to already exist and remain unchanged from the end of Phase 1. The Microsoft team expects to reuse them based on experience from Phase 1. .

Solution testing The following table provides information about the types of testing, responsibilities, and environments to be used for conducting testing activities.

Test type Description Responsible Provides test data or cases

Guidance and support

Environment

1 Unit testing Documenting and completing unit-test cases is the responsibility of the developers.

Microsoft Microsoft Customer Development

2 Functional testing

Functional testing focuses on functionality meeting the design.

Customer Customer Microsoft Test

3 Data Validation

Data Validation testing, post migration focuses on accuracy of the data in the new data model in Dynamics 365

Customer Customer Microsoft Test

4 End-to-end (E2E) and User Acceptance Testing

(UAT)

Done to determine whether the functionality meets the design specifications. This is achieved by running tests, with a focus on

Customer Customer Microsoft Test

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 7 of 29

Test type Description Responsible Provides test data or cases

Guidance and support

Environment component development and the complete process flow. Test cases are based on the functional specifications and business requirements provided by ELRB.

During testing, the Customer and Microsoft will jointly agree on Solution-related defects and their severity. The Microsoft team will fix in scope S1 and S2 defects as allowed by remaining capacity. Defect severity is defined in the table in Appendix 8.2 Defect severity.

Training and knowledge transfer Informal knowledge transfer will be provided throughout the project by Microsoft. Informal knowledge transfer is defined as Customer’s staff working alongside Microsoft staff. No custom training materials will be developed or delivered as part of formal training or informal knowledge transfer. Any additional involvement by Microsoft required to address Customer’s training needs will be addressed according to the Change management process as specified in Section 4.4 in this SOW.

2.2 Areas out of scope

Any area not explicitly included in the Scope details section is out of scope for Microsoft during this project. Areas out of scope for this project are listed in the following table.

Area Description

Product licenses Product licenses (Microsoft or non-Microsoft) will not be provided as part of this SOW. The Customer is responsible for acquiring all product licenses required as a result of this SOW.

UAT The customer owns responsibility of creating and executing UAT test cases.

Microsoft will offer guidance during UAT but will not execute test cases for ELRB.

Hardware Hardware will not be provided under this SOW. The Customer is responsible for acquiring all necessary hardware.

Customization No custom code (plug-ins, JavaScript, etc.) will be delivered as part of this project.

Infrastructure setup

Infrastructure setup (required hardware and software), including the setup of a high availability, disaster recovery, or load-balanced environments is not in the scope of this SOW.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 8 of 29

Area Description

Legacy systems Microsoft will not be responsible for supporting legacy client systems.

Integration with third-party software

Microsoft will not be responsible for integration with third-party software.

Source code review

The Customer will not provide Microsoft with access to non-Microsoft source code or source code information. Source code reviews will not be performed.

Requirements gathering

Microsoft will analyze the requirements documented for processes identified as in scope; gathering of requirements is not in scope under this SOW.

Documentation Preparation of documentation regarding existing processes, previous standards, policies, or existing guidelines is out of the scope of this SOW.

Process reengineering or process mapping

• The design of functional business components of the Solution, unless specifically included in scope and delivered by MCS staff, is out of scope.

• Process engineering or reengineering activities are outside of the scope of the Microsoft responsibilities and will be assumed to be completed by the Customer prior to the start of the Config & Dev - Analysis activity set.

Adoption & Change Management

(ACM)

Design or redesign of the Customer’s functional organization, unless specifically included in scope and delivered by MCS staff, is out of scope.

Global solution needs

Language implementations that are not part of the core product will not be applied as part of this SOW.

Localization Localization of the user interface is out of scope.

Performance & Load Testing

Conducting Performance and Load testing is out of scope.

Information security policies

Creation of Information security policies or application development security policies is out of scope.

Application security code review

Security review will not be conducted for any application or applications outside the scope of this engagement.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 9 of 29

Area Description

Comprehensive security and compliance assessment, mitigation, or implementation

Microsoft security and compliance review is limited to the scope of features within this engagement and is intended to target the commercially reasonable context of this application in view of the Customer’s information security, compliance, and data privacy policies.

A complete or comprehensive security and compliance assessment for the customer marketplace and technology environment is out of scope, along with mitigation or security solutions not explicitly included in the scope of the engagement per General project scope section.

Regulatory Standards

Attestation/Certification of the application solution to any regulatory standards.

3 Delivery approach, timeline, and management

3.1 Approach

This project will make use of the Iterative Sure Step 365 methodology to complete this SOW. This SOW covers the following phases: Initiation, Config & Dev, Solution Testing, Deployment and Support Transition phases.

Since this engagement will be implemented with a Fixed Capacity described in the ESWO, the scope of this engagement may vary. ELRB is responsible for making all scope prioritization decisions. If capacity is consumed prior to completion of the full scope of this document, and no Capacity is added, some elements of this scope will not be delivered.

The estimated capacity does not create a commitment to deliver all the scope.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 10 of 29

Phase descriptions

Phase name Phase description

Initiation The Initiation phase represents the official start of the project from a delivery team perspective. This phase includes the activities required to initiate and effectively prepare and plan the project with the Microsoft and Customer team members. This is the planning phase of the project in which the Microsoft and Customer teams will separately prepare their proposals and then come together to agree on a methodology and project plan and confirm schedules for the requirements workshops.

Solution Modeling

The Solution Modeling phase enables the project team to align the core capabilities of Microsoft Dynamics 365 with the Customer’s desired solution and outcomes. During this phase, the team will review the project scope and model the solution leveraging Dynamics 365 product features and capabilities. The goals of the Solution Modeling phase are:

• Establish a shared understanding of proposed capabilities linked to business outcomes.

• Create/update a Backlog of epics, process, features, and user stories.

• Establish solution strategy designs including data, test & solution performance strategies.

• Perform backlog planning per sprint and release plan for go live

• Perform a backlog review process to align outcomes based on the initial scope and to help identify any changes required for the solution.

Config & Dev The Config and Dev phase enables a defined set of functionalities to be completed in a parallel, iterative manner that enhances quality and consistency through feedback loops after each sprint. The goals of Config and Dev phase are:

• Analysis, functional & technical design of user stories/features aligned with solution strategies.

• Configuration & development of epics, process, features, and user stories

• Configuration & development of Interfaces, reporting & data migration activities slated for a release.

• Unit & sprint testing.

• Solution deployment pipelines & release management.

• Sprint review and demo session

• Data migration scripts and development

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 11 of 29

Phase name Phase description testing

The primary goal of the Solution Testing phase is to validate solution quality, process compliance, and tested process performance. The goals of the Solution Testing phase are:

• Validate that the solution has been configured and customized to meet the overall Customer requirements in alignment with this SOW and change requests.

• Perform User Acceptance Test (UAT).

• Validate solution performance.

• Finalize security assessment & reviews.

• Validate production-ready data

• Application should be ready for go-live, and its users adequately trained to adopt the system as per the acceptance criteria outlined in the SOW.

• Operational readiness and Customer-owned business readiness plan preparations.

• Long term support readiness plan preparations.

Deployment The Prepare & Deploy phase focuses on deploying the solution to the production environment. At the end of this phase, the application is released in production environment(s). The goals of the Prepare & Deploy phase are:

• Go-live readiness

• Cutover plan execution

• Application is released in production environment.

• Completion of production data migration.

• Completion of operation readiness plans.

• Completion of Customer-owned business readiness plans.

Support Transition

The Support phase occurs after deployment of the solution (when the application is live). This phase focuses on providing support for the transition from the implementation to the long-term care team. The goals of the Support phase are:

• Provide transitional application support by assisting with solution management, defect remediation, and knowledge transfer.

• Facilitate successful application, solution management, and functional knowledge transfer to long term care teams.

• Handoff all support processes from the implementation team to the Customer.

• Close and complete project/release/contract activities as required

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 12 of 29

Phase outcomes

Phase Description Outcomes

Initiation • Facilitation of Customer Readiness prior to the Initiation phase.

• Facilitation of proper handoff from the sales team to the delivery team.

• Alignment among all teams on the required Initiation activities.

• Alignment of the solution approach, methodology, tools, schedule, and governance aspects of the project among the Customer and Microsoft.

Outcomes Primary Responsibility

Staffing plans and resource assignment

Microsoft

Sales to delivery handoff

Microsoft

Project plan Microsoft

Setup Azure DevOps or other project tools

Microsoft and

ELRB

Grant environment and system access

ELRB

Project governance plan and rhythm of the business

Microsoft &

ELRB

Review of outcomes, OKRS, with the ELRB leadership

Microsoft &

ELRB

Phase exit criteria:

There are no formal deliverables for this phase.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 13 of 29

Modeling

• A configure-first approach.

• Performance of out-of-the-box fit requirements validations.

• Alignment of delivery product with

Dynamics 365, based on the project scope.

• Introduction of business subject matter experts (SMEs). These business SMEs usually work closer to the day-to-day process.

Outcomes Primary Responsibility

Elaborate requirements / user stories

Microsoft and

ELRB

Approve all in-scope user stories and features

ELRB

Development plan and a schedule for all gaps

Microsoft &

ELRB

Sprint plan and schedule

Microsoft

Develop test strategy ELRB

Finalized change request for additional gaps and requirements (as needed)

Microsoft and

ELRB

Phase exit criteria:

All in-scope features and user stories with its detailed description and acceptance criteria have been approved by ELRB in

ADO.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 14 of 29

Config & Dev • Completion of gap analysis, development, and iteration testing.

• Opportunity for the Customer to test smaller blocks of functionality to improve defect management and solution acceptance.

• Opportunity for the Customer to prepare for training and transition the rest of the organization to the enhanced system.

• Promotion of efficient use of resources by advancing to the next activity set upon completion of the current set. For example, completion of the Analysis and Design set triggers Development and Iteration testing.

• Conduct discovery of ELRB’s baseline data protection requirements through completion of a data protection questionnaire (DPQ)

• Identify the applicable issues and compliance requirements that may arise, based solely on the information provided by ELRB as part of the DPQ.

• Perform a review of solution design to identify architecture-level security issues and create security findings report

Outcomes Primary Responsibility

Update solution design in ADO for each in-scope user stories and features, as needed

Microsoft

Configure solution to address all in-scope user stories and features

Microsoft

Defect management plan, triage, and fixes

ELRB and Microsoft

Perform functional testing for each in-scope features and user stories

ELRB

Develop data migration scripts

Microsoft

Document E2E and UAT test scripts

ELRB

Validate solution by testing smaller block of functionality, as needed

ELRB

Security Findings When required to obtain direction from the Customer, Microsoft at its discretion, may share security findings from the review of solution design added to the project planning, risk log, or task backlog as applicable.

Microsoft

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 15 of 29

Phase exit criteria:

All in-scope features and user stories have been configured, unit and functional tested for its completion.

Solution testing • A tested solution that matches Customer requirements.

• Users that have been trained to perform testing.

• Completed updates to all design documents.

• Completion of standard operating procedures and training materials.

• Validation of production-ready data.

• Completion and testing of defect fixes.

Outcomes Primary Responsibility

Defect management plan, triage, and fixes

Microsoft

E2E testing complete ELRB

UAT complete ELRB

End user training for

UAT

ELRB

Data validation testing ELRB

Functional solution updated

Microsoft

Deployment guide Microsoft

Phase exit criteria:

Deliverable phase complete sign-off document of the functional solution in the UAT environment, at the conclusion of the UAT round of testing.

Deployment • Deployment of the solution to the production environment.

• Completion of configuration and security setup in the production environment.

• Execute the cutover plan.

• Preparation of the solution for go live.

• Preparation of the solution for go live.

• Smoke test the production deployment.

Outcomes Primary Responsibility

Deployment of the solution to the Production environment

Microsoft

End user provisioning including access control

ELRB

Smoke test production deployment

Microsoft and

ELRB

Phase exit criteria:

Deliverable phase complete sign-off document of the functional solution with

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 16 of 29 the approved UAT solution deployed to the Production environment.

Support Transition

• Support for the transition of solution by assisting with solution management, defect remediation, and knowledge transfer.

• Capacity based production support with focus on assisting ELRB in resolution of S1 and S2 issues.

• Post-production support transition to the Customer support team.

• Handoff of all solution components and environments to the Customer support team.

• Complete data protection clean-up activities to Remove Customer data per Microsoft’s commitments to Customer.

• Ensure all relevant credentials or secrets related to the project scope have been provided to ELRB.

Outcomes Primary Responsibility

Support transition workshops

Microsoft

Monitor production environment

ELRB

Assist in defect resolution

Microsoft

Defect resolution and on-going deployments

ELRB

Phase exit criteria:

Deliverable phase complete sign-off document noting the elapsed duration of the phase.

Phase-end checkpoints Microsoft and the ELRB will complete checkpoints at the end of the Initiate, Solution Modeling, Config and Dev, and Solution Testing phases to compare the current project plan (scope, timeline, budget, and assumptions) against the baseline for the project established in the SOW (and any approved change requests), and to determine whether adjustments should be made during future phases and activities. The phase-end checkpoints are a critical scope control function and will be supported by the Microsoft and ELRB project managers and sponsors.

3.2 Timeline

During the Initiation phase, a detailed timeline will be developed. The timeline below is a high-level representation; all dates and durations are relative to the engagement start date and are estimates only.

The estimated timeline is based upon the assumption of uninterrupted delivery from the start of the engagement. In addition, it is based on the current understanding of technical and architectural complexity and access to data. If there are delays to the schedule of the engagement or if the level of complexity exceeds what is assumed, or data sources are not readily available, the change management process may be used to extend the timeline and potentially add cost to ELRB.

Microsoft will provide a delivery team described in the Engagement organization section for the term specified in the WO or until the capacity defined in the WO is consumed.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 17 of 29

The high-level timeline of the engagement is depicted in the following graphic.

Should the elapsed time for each service or the total elapsed engagement duration extend beyond the estimated weeks, additional effort may be required, which will be processed through the change management process described in this SOW.

3.3 Completion and definition of done

Delivery sprint completion As part of each sprint review, the Customer will review each backlog item (user story or defects) completed in the sprint and confirm whether it is considered done using the Definition of Done agreed during sprint planning. Each backlog item that is done will be recorded as such in Azure DevOps. The results will also be captured as part of the sprint completion report.

The status of each completed backlog item must be updated in Azure DevOps within five days after the sprint review meeting is complete.

Upon the completion of each sprint, as part of the sprint review activity, the capacity available will be assessed with the Customer Product Owner against the required capacity as per the backlog items. This might result in a change in contracted capacity/fees which will be managed through the Change management process described in this SOW.

Backlog item completion Backlog items (user stories or defects) do not require formal sign-off or Customer acceptance when they are completed by the delivery team. Any defects found in a finished backlog item will be added to the product backlog as a defect and prioritized by the Customer product owner with the other backlog items.

A finished backlog item may also prompt the Customer product owner to include additional backlog items to enhance the software.

3.4 Delivery Management

During the project, Microsoft will complete documentation and submit the solution for the Customer’s review and approval.

Documentation Documentation is managed using a continuous documentation approach. The Azure DevOps Wiki will be used to maintain documentation. The Azure DevOps Wiki will be provisioned as a part of the setup during

Initiation Week 1

Solution Modeling Week 2

Config & Dev Weeks 3 - 5

Testing Weeks 6 - 7

Deploy Week 8

Support Weeks 9 - 10

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 18 of 29

Initiation. If documents are required to be tracked for compliance or for internal control reasons, they will be managed using the change management process.

Solution approval and turnaround time

• All solution deliverables will be submitted as releases to the Customer for review and acceptance by the agreed-upon date. The Customer will review the deliverable within two business days and provide feedback by logging the defects.

• The Customer project manager will be responsible for organizing internal reviews and collating feedback into a single document. This will include making test scripts, test files, and testing staff available.

• Microsoft and the Customer will review defects within two business days and agree on the potential impacts and their priorities. The acknowledged bugs will be corrected according to priority. Those agreed-upon changes will be submitted using the change management process described in this

SOW.

• Once a bug has been resolved, the originator will be informed of its resolution, and the Customer will then have three business days to provide additional feedback or to confirm that the bug has been resolved. Additional feedback that requires resolution will be added as part of the ongoing project management.

Solution acceptance criteria Any solution deliverable (code, application, or configuration) with zero Severity S1 and S2 defects will be accepted.

4 Engagement governance The project will be managed by a part-time Microsoft project manager, who will work with the Customer project manager. The Microsoft project manager will be responsible for the overall delivery of Microsoft Services as specified in the following table. The project manager will report to the project management office, which will consist of the Customer sponsors, Customer program manager, and the Microsoft delivery leader.

The governance structure and processes the team will abide by for the engagement are described in the following sections. Following Work Order execution, the engagement governance and management team, jointly staffed by Microsoft and ELRB , should be established before the start of the engagement.

This allows the key stakeholders to become acquainted with the processes, communication rhythm, and tools planned for the reporting of status, issues/risks, and financials prior to the official engagement kickoff. Note that at defined intervals, the joint team will review the responsibilities of the engagement governance structure. This might result in an extension or reduction of the engagement governance management team roles and will be managed through the change management process.

4.1 Engagement communication

The following will be used to communicate during the project:

• Status reports: the Microsoft team will prepare and issue regular status reports to project stakeholders per the frequency defined in the communication plan.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 19 of 29

• Status meetings: the Microsoft team will schedule regular status meetings to review the overall project status, the acceptance of deliverables, and review open problems and risks.

• ELRB will assist in facilitating the status meetings and will review and align on the status reports.

4.2 Risk and issue management

The following general procedure will be used to manage active project issues and risks during the project:

• Identify: identify and document project issues (current problems) and risks (potential problems that could affect the project).

• Analyze and prioritize: assess the potential impact and determine the highest priority risks and problems that will be actively managed.

• Plan and schedule: determine the strategy for managing priority risks and issues and identify a resource who can take responsibility for mitigation and remediation.

• Track and report: monitor and report the status of risks and problems.

• Escalate: escalate to project sponsors the high-impact problems and risks that the team is unable to resolve.

• Control: review the effectiveness of risk and issue management actions.

Active issues and risks will be regularly monitored during the project.

4.3 Business governance

During the project, the Customer will be required to decide whether to accept the customization of out-of-the-box solution functionality in order to address business requirements. This will require detailed understanding and evaluation of the business need that drives the request for customization and the cost and possible impact to the project if the customization is accepted. The evaluation and acceptance of the customization as it is compared to alternatives to modifying business processes or implementing process work-arounds is a Customer responsibility. The business governance steps are:

• The Microsoft project team will identify the request for customization as work over and above the requirements stated in this SOW.

• The Microsoft project team will provide estimates in alignment with the change management process defined in this document and will provide alternatives in the form of process modifications or work-arounds that will make the use of out-of-the-box functionality possible.

• The Customer business process lead, or analyst will perform a business case evaluation of the potential benefits of the customization compared to the cost and impact of the project and evaluate the alternatives.

• The Customer project sponsor will determine who at the appropriate level of the Customer organization has the authority to approve business cases and accept the customization at the start of the project.

4.4 Change management process

During the project, either party can request, in writing, additions, deletions, or modifications to the Services described in this SOW (“change”). Approved changes will be managed through amendments, which may lead to additional costs and schedule impacts. Microsoft shall have no obligation to commence work in connection with any change until the details of the change are agreed upon in an amendment signed by the authorized signatories from both parties.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 20 of 29

Within three consecutive business days of receipt of the proposed amendment, ELRB must either indicate acceptance of the proposed change by signing the amendment or advise us not to perform the change. If you advise us not to perform the change, we will proceed with the original agreed-upon Services only. In the absence of ELRB acceptance or rejection within the previously noted time frame, we will not perform the proposed change.

4.5 Escalation path

The Microsoft project manager will work closely with the Customer project manager, sponsor, and other designees to manage project issues, risks, and change requests as described previously. The Customer will provide reasonable access to the sponsor or sponsors in order to expedite resolution. The standard escalation path for review, approval, or dispute resolution is as follows:

• Project team member (Microsoft or the Customer)

• Project manager (Microsoft and the Customer)

• Microsoft Delivery Manager

• Microsoft and the Customer project sponsor

Critical path decisions

Throughout the project, Microsoft will submit requests for decisions that the Customer must make.

Decisions are assigned due dates, and it is assumed that the Customer will provide the required feedback or make decisions either by the agreed-upon due date or within three business days of submittal.

Some decisions requested will be determined by Microsoft as critical path decisions with key dependencies, and these will be submitted with a written notice of decision (NOD) request. If the NOD request is not acted on by the due date, it may affect the project critical path and will be addressed as a project change request and submitted through the Change management process.

4.6 Engagement completion

Microsoft will provide Services defined in this SOW to the extent of the fees available and the period of performance specified in the WO. If additional Services are required, the change management process will be followed, and the contract modified. The engagement will be considered complete when at least one of the following conditions has been met:

• All available capacity has been consumed.

• The period of performance (Term) of the engagement has expired.

• All Microsoft activities and backlog items have been completed.

• The WO has been terminated.

Due to the nature of this engagement, the final backlog items produced at the time of the conclusion of the engagement may or may not include the completion of all of the items in the product backlog identified by the Customer product owner. The Microsoft team will rely on the Customer Product Owner to determine priorities in the product backlog so that the important backlog items specified by the Customer can be completed during the engagement.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 21 of 29

5 Engagement organization

5.1 Organization structure

This section describes the overall project organization structure, reporting relationships, and key project roles.

The project will be organized as depicted in the following diagram.

5.2 Project roles and responsibilities

Customer responsibilities

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 22 of 29

Role Responsibilities Project commitment

Customer project sponsor Make key project decisions, serve as a point of escalation, and clear project roadblocks.

Part-time—15%

Customer project manager • Serve as the primary point of contact for the Microsoft team.

• Manage and coordinate the overall project to deliver it according to schedule.

• Take responsibility for Customer resource allocation, risk management, project priorities, and communication with executive management.

• Coordinate decisions within 3 business days, or within an otherwise agreed-upon timeline.

Full-time

Product Owner • Works to eliminate ELRB-related issues hindering or impeding implementation.

• Serves as the single point of contact for decisions about product backlog items and prioritization.

• Takes responsibility for making decisions on services and/or product features.

• Defines acceptance criteria for deliverables.

• Actively participates in all reviews.

• Takes responsibility for planning UAT and providing appropriate ELRB resources for testing.

• Provides Microsoft teams with prompt answers to questions affecting development activities and, more generally, services to be delivered.

Part time – 25%

Technical lead or technical manager

• Serve as primary technical point of contact for the team.

• Take responsibility for technical architecture and code deliverables.

Part-time—25%

Lead process lead or lead business analyst

• Serve as primary functional point of contact for the team that is responsible for functional business analysis.

• Make decisions regarding Solution processes, customizations, and work-arounds.

• Serve as a liaison to the broader team and take responsibility for streamlining and standardizing processes.

• Develop test scripts and scenarios and perform tests.

Full-time

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 23 of 29

Role Responsibilities Project commitment

Customer Security Contact • Provide technical documentation for the contract-identified/engagement specific data protection requirements, standards and other identified Customer expectations for security and privacy

• Provides access to existing Customer security policy, standards, and answers Microsoft questions on requirements

• Participates in data classification sessions, if applicable

• Completes post-project review, credential rotation, access removal

Part-Time

Microsoft responsibilities

Role Responsibilities

Delivery Management Executive (DME)

• Serve as the primary point of contact for overall satisfaction and concerns related to Microsoft Services.

• Serve as the single point of contact for billing issues, personnel matters, and contract extensions.

• Facilitate project governance activities.

• Oversees all service delivery engagements with ELRB.

• Serves as the arbiter of engagement issues.

Project manager • Manage the Microsoft project delivery and coordinate the overall project to deliver it according to schedule.

• Serve as the primary point of contact for the Microsoft team.

• Take responsibility for issue and risk management, change management, project priorities, weekly status communication, and the weekly status meeting.

• Coordinate Microsoft resources and partners subcontracted to Microsoft, including staffing, task assignments, and status reporting.

• Report on project status on a weekly basis.

• Coordinates decisions within 3 business days, or otherwise agreed timeline.

• Takes responsibility for capturing and managing success expectations.

• Provide Manage rigorous change control, registering changes for impact analysis and resolution.

• Validate that items requiring action are resolved in a timely fashion, reporting status and escalation as required.

Architect (Solution) • Provide technical oversight.

• Verify whether Microsoft-recommended practices are being followed.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 24 of 29

Role Responsibilities

• Coordinate overall solution design.

• Escalate technical issues for resolution.

• Provide knowledge transfer to Customer resources.

Dynamics Consultants

• Participate in every aspect of the implementation from analyzing the Customer’s business requirements to configuring the Microsoft Dynamics 365 application.

Assist the Customer with the planning and implementation of the test strategy, including data migration tests, and user acceptance tests.

• Configure the Microsoft Dynamics 365 application.

• Take responsibility for overall development quality, processes, and tracking.

Customer and Microsoft task assignments

Data migration

Task Microsoft ELRB Required by

Define the data migration requirements. X Solution Modeling

Define the data migration strategy X Solution Modeling

Extract from Access X Config & Dev

Perform data cleansing. X Config & Dev

Perform data mapping (legacy to updated). X X Config & Dev

Update format templates. X Config & Dev

Provide data test loads (three loads). X Test

Migrate Data to Production X Deployment

6 Customer responsibilities and engagement assumptions

6.1 Customer responsibilities

The Customer is also required to:

• Provide information:

o This includes accurate, timely (within three business days or as mutually agreed upon), and complete information required for the engagement.

• Provide Microsoft with access to ELRB’s security policy, standards, and/or practices documentation relevant to the application scope.

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 25 of 29 o Provide Microsoft with access to the customer’s architecture or integration documents and security policy recommendations.

• Provide access to people and resources:

o This includes access to knowledgeable ELRB personnel, including business user representatives, and access to funding if additional budget is needed to deliver project scope.

• Provide access to systems:

o This includes access to all necessary ELRB networks, systems, and applications (remote only).

• Manage non-Microsoft resources:

o The Customer will assume responsibility for the management of all Customer personnel and vendors who are not managed by Microsoft.

• Manage external dependencies:

o ELRB will facilitate any interactions with related projects or programs in order to manage external project dependencies.

• Others

• Attend data classification sessions, as applicable, and provide input.

o Attend information gathering and design review sessions o Review product in each integration or sprint for conformance to customer’s market and/or operational requirements.

o At the end of the engagement:

Remove access for the Microsoft delivery team from all systems.

Rotate/change relevant credentials or secrets related to the project scope for ongoing production deployment at Customer.

Review production roles, permissions, and security configurations to ensure confirm suitability and conformance to ELRB’s market, policies, and security programs.

6.2 Engagement assumptions

The project scope, Services, fees, timeline, and our detailed Solution are based on the information provided by ELRB to date. During the project, the information and assumptions in this SOW will be validated, and if a material difference is present, this could result in Microsoft initiating a change request to cover additional work or extend the project duration. In addition, the following assumptions have been made:

• All work completed in Phase 1 remains unchanged and the environments (dev, test, prod) are as they were left at the end of Phase 1. This ensures that the project can start where it left off without additional complications or delays.

• If ELRB is unable to meet their responsibilities and activities listed in this Statement of Work, within the timeframes requested by Microsoft, a change request at additional cost to IELRB may be needed to complete the desired objectives or to extend the schedule

• Work day:

o Microsoft employees will follow the standard Microsoft (or appropriate subsidiary) workday and work week based on where the Microsoft employee is located unless otherwise agreed to jointly between the Microsoft employee and ELRB. Exceptions will be coordinated by the Microsoft Delivery Management Executive.

• Remote working:

o The Microsoft project team will perform Services remotely.

• Language:

SOW-DYN365COMBv2.0(WW)(English)(Mar2019) Page 26 of 29 o All project communications and documentation will be in U.S. English. Local language support and translations will be provided by the ELRB.

• Staffing:

o If necessary, Microsoft will make staffing changes. These may include, but are not limited to, resources, and engagement roles.

o Microsoft reserves the right to utilize whichever labor categories, which could include certain vetted and approved subcontractors, in whatever quantities, in our sole discretion, are appropriate to perform the professional services outlined in this SOW.

o If any Security clearances are required, those need to be identified by ELRB before contract signature and outlined in the Statement of Work. If Security clearance becomes required after contract signature, it may cause engagement delays or delays in staffing and engagement start.

o Resource mobilization for staffing the engagement will be, on average, 4 weeks from contract WO execution date. Factors that could shorten or lengthen that time frame include: resource availability, how lengthy ELRB onboarding process may be, what types of skills are required, etc.

o Microsoft employees may be based within the US or outside of the US unless ELRB has specific requirements for where the engagement team members need to be based. If ELRB has requirements on where Microsoft resources can be located, those need to be identified by ELRB before contract signature and outlined in the Statement of Work.

o Any ELRB required onboarding or compliance training and/or activities is not included in the estimation. If any are required, the time required by each engagement team member to complete them will need to be estimated in the contract as billable activities or the change management process outlined in the Change Management Process…