Common use of Project Management Plan Clause in Contracts

Project Management Plan. Describes the overall project management approach and schedule throughout the lifecycle of the project. The Project Management Plan will define the following (at a minimum): a) Risk and Issue Management Plans & Logs – Risk and Issue Management Plan, Escalation Plan, and Risk and Issue Register (which must comply with the requirements of the Texas Project Delivery Framework) b) Integrated Change Management Plan – Outlines the process for identifying, evaluating, authorizing, and implementing proposed changes in requirements, schedule, and budget, as well as solution design and acceptance criteria i) For change management, a change is defined as any modification within the scope of or reasonably related to the SOW content including any content in all SOW attachments, such as the Requirements Traceability Matrix. If a potential change is identified by a member of the project team, including the Contractor or OCA (or other internal/external stakeholder), then the change management process outlined below shall be used to initiate a formal Change Request. Similarly, whenever significant deviations are anticipated or reported against implementation processes, schedule or cost, a Change Request is required to re-baseline the project. ii) Change Requests can be initiated at any stakeholder level and may or may not require a formal contract change Activities Work Products  Develop weekly status reports and schedule ongoing communications for the project  Provide Ongoing Project Management Duties – Provide weekly project plan and schedule updates, weekly status reporting, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the Contractor’s Project Manager shall participate in project Steering Committee meetings and JCIT quarterly meetings as required. depending upon its scope. Either OCA or Contractor may initiate a Change Request for a desired process change, additional funding, and/or a longer timeline as conditions may change on the project over time. iii) During the project, all potential Change Requests must be brought to the Steering Committee (SC) that is composed of key stakeholders from the Texas Judiciary and OCA executive staff and facilitated by the OCA Project Manager. The SC serves as the “Change Control Board” for this project. The Change Request must contain, at a minimum, the description of the change, the schedule to implement the change, and a fixed price based on the number of hours required. iv) The SC is responsible for making decisions on approval/rejection and subsequent prioritization and timing of all Change Requests. v) When the SC reviews Change Requests, the SC may approve the Change Request, consider alternatives, direct the project team to do more research, reject the Change Request and continue the project, or reject the Change Request and request a different change. The SC considers whether the Change Request undermines or supports the project benefits or the project alignment with OCA’s major goals, strategy, budget, and/or direction. vi) Any changes to the Statement of Work or the Service Level Agreement are subject to OCA’s prior written approval. In the absence of any modifications, the performance targets, Service Level Requirements, and measurement intervals in the Service Level Agreement shall apply during the Term of the Agreement.  Deployment Planning – Conduct workshops with OCA and other stakeholders to finalize approach for deploying the solution into production, including possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.  Develop Project Deployment Plan 2) Project Deployment Plan (e.g., transition planning to finalize phased rollout details) – a) Finalized approach for deploying the solution into production including any phasing strategies, site specific considerations, and benefits and risks of strategy: i) Overview of the current environment and considerations for deployment ii) Identification of high-risk transition areas and impact, mitigation strategies, and recommended mitigation actions iii) Any ongoing risks, based on finalization of phasing approach, must be tracked in a risk log iv) Any decisions that impact the schedule must be documented in the project schedule v) Any cutover consideration(s) must be documented in the final Cutover Plan b) Contractor must also provide a finalized project organization chart Activities Work Products  Develop a baseline project schedule to reflect the project timelines, milestones, and deliverables 3) Baseline Project Schedule – Project work plan and schedule, including Xxxxx chart(s) and a project calendar in Microsoft Project that is developed and maintained in accordance with industry best practices. The work plan will reflect any changes from the baseline plan originally agreed to during the project initiation and be updated/published on a weekly basis. The project schedule will include the following components (at a minimum): a) A consolidated view of the activities, activity descriptions, and activity durations assigned to stakeholders and Contractor b) Resources (OCA, other stakeholders, Contractor, and third- party contractors) assigned to each activity and their required level of effort c) A list of all required project deliverables tied to the appropriate project milestones d) Identification of all key project milestones e) Deliverable approval periods compliant with OCA’s Deliverable Expectations Document process as described in the following section Deliverable Expectations Document f) A critical path analysis and reporting process

Appears in 1 contract

Samples: Master Services Agreement

AutoNDA by SimpleDocs

Project Management Plan. Describes the overall project management approach and schedule throughout the lifecycle of the project. The Project Management Plan will define the following (at a minimum): a) Risk and Issue Management Plans & Logs – Risk and Issue Management Plan, Escalation Plan, and Risk and Issue Register (which must comply with the requirements of the Texas Project Delivery Framework) ). b) Integrated Change Management Plan – Outlines the process for identifying, evaluating, authorizing, and implementing proposed changes in requirements, schedule, and budget, as well as solution design and acceptance criteria criteria. i) For change management, a change is defined as any modification within the scope of or the RFO that is reasonably related to the SOW content including any Activities Work Products thirty (30) days of contract execution. The kickoff meeting will provide an overview of the project objectives, plans, project scope and schedule, introduce the Contractor’s project team and roles and responsibilities, and outline project start-up procedures. • Develop weekly status reports and schedule ongoing communications for the project • Provide Ongoing Project Management Duties – Provide weekly project plan and schedule updates, weekly status reporting, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the Contractor’s Project Manager shall participate in project Steering Committee meetings and JCIT quarterly meetings as required. content in all SOW attachments, such as the Requirements Traceability MatrixMatrix (RTM). If a potential change is identified by a member of the project team, including the Contractor or OCA (or other internal/external stakeholder), then the change management process outlined below shall be used to initiate a formal Change Request. Similarly, whenever significant deviations are anticipated or reported against implementation processes, schedule or cost, a Change Request is required to re-re- baseline the project. ii) Change Requests can be initiated at any stakeholder level and may or may not require a formal contract change Activities Work Products  Develop weekly status reports and schedule ongoing communications for the project  Provide Ongoing Project Management Duties – Provide weekly project plan and schedule updates, weekly status reporting, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the Contractor’s Project Manager shall participate in project Steering Committee meetings and JCIT quarterly meetings as required. depending upon its scope. Either OCA or Contractor may initiate a Change Request for a desired process change, additional funding, and/or a longer timeline as conditions may change on the project over time. iii) During the project, all potential Change Requests must be brought to the Steering Committee (SC) that is composed of key stakeholders from the Texas Judiciary and OCA executive staff and facilitated by the OCA Project Manager. The SC serves as the “Change Control Board” for this project. The Change Request must contain, at a minimum, the description of the change, the schedule to implement the change, and a fixed price based on the number of hours required. iv) The SC is responsible for making decisions on approval/rejection and subsequent prioritization and timing of all Change Requests. v) When the SC reviews Change Requests, the SC may approve the Change Request, consider alternatives, direct the project team to do more research, reject the Change Request and continue the project, or reject the Change Request and request a different change. The SC considers whether the Change Request undermines or supports the project benefits or the project alignment with OCA’s major goals, strategy, budget, and/or direction. vi) Any changes to the Statement of Work or the Service Level Agreement are subject to OCA’s prior written approval. In the absence of any modifications, the performance targets, Service Level Requirements, and measurement intervals in the Service Level Agreement shall apply during the Term of the Agreement. Deployment Planning – Conduct workshops a vision session workshop with OCA OCA, Early Adopter Clerk’s Office, and other stakeholders during the Early Adopter Clerk’s Office implementation to finalize approach for deploying the solution into production, including possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.  Develop Project Deployment Plan 2) Project Deployment Plan (e.g., transition planning to finalize phased rollout details) – a) Finalized approach for deploying the solution into production including any phasing strategies, site specific considerations, and benefits and risks of strategy: i) Overview of the current environment and considerations for deployment deployment. Activities Work Products possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives. ii) Identification of high-risk transition areas and impact, mitigation strategies, and recommended mitigation actions actions. iii) Any ongoing risks, based on finalization of phasing approach, must be tracked in a risk log log. • Develop Project Deployment Plan iv) Any decisions that impact the schedule must be documented in the project schedule schedule. v) Any cutover consideration(s) must be documented in the final Cutover Plan Plan. b) Contractor must also provide a finalized project organization chart Activities Work Products  Develop a baseline project schedule to reflect the project timelines, milestones, and deliverables 3) Baseline Project Schedule – Project work plan and schedule, including Xxxxx chart(s) and a project calendar in Microsoft Project that is developed and maintained in accordance with industry best practices. The work plan will reflect any changes from the baseline plan originally agreed to during the project initiation and be updated/published on a weekly basis. The project schedule will include the following components (at a minimum): a) A consolidated view of the activities, activity descriptions, and activity durations assigned to stakeholders and Contractor b) Resources (OCA, other stakeholders, Contractor, and third- party contractors) assigned to each activity and their required level of effort c) A list of all required project deliverables tied to the appropriate project milestones d) Identification of all key project milestones e) Deliverable approval periods compliant with OCA’s Deliverable Expectations Document process as described in the following section Deliverable Expectations Document f) A critical path analysis and reporting processchart.

Appears in 1 contract

Samples: Master Services Agreement

Project Management Plan. Describes the overall project management approach and schedule throughout the lifecycle of the project. The Project Management Plan will define the following (at a minimum): a) Risk and Issue Management Plans & Logs – Risk and Issue Management Plan, Escalation Plan, and Risk and Issue Register (which must comply with the requirements of the Texas Project Delivery Framework) b) Integrated Change Management Plan – Outlines the process for identifying, evaluating, authorizing, and implementing proposed changes in requirements, schedule, and budget, as well as solution design and acceptance criteria i) For change management, a change is defined as any modification within the scope of or reasonably related to the SOW content including any content in all SOW attachments, such as the Requirements Traceability Matrix. If a potential change is identified by a member of the project team, including the Contractor or OCA (or other internal/external stakeholder), then the change management process outlined below shall be used to initiate a formal Change Request. Similarly, whenever significant deviations are anticipated or reported against implementation processes, schedule or cost, a Change Request is required to re-baseline the project. ii) Change Requests can be initiated at any stakeholder level and may or may not require a formal contract change depending upon its scope. Either OCA or Contractor may initiate a Change Request for a desired process change, Activities Work Products Develop weekly status reports and schedule ongoing communications for the project Provide Ongoing Project Management Duties – Provide weekly project plan and schedule updates, weekly status reporting, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the Contractor’s Project Manager shall participate in project Steering Committee meetings and JCIT quarterly meetings as required. depending upon its scope. Either OCA or Contractor may initiate a Change Request for a desired process change, additional funding, and/or a longer timeline as conditions may change on the project over time. iii) During the project, all potential Change Requests must be brought to the Steering Committee (SC) that is composed of key stakeholders from the Texas Judiciary and OCA executive staff and facilitated by the OCA Project Manager. The SC serves as the “Change Control Board” for this project. The Change Request must contain, at a minimum, the description of the change, the schedule to implement the change, and a fixed price based on the number of hours required. iv) The SC is responsible for making decisions on approval/rejection and subsequent prioritization and timing of all Change Requests. v) When the SC reviews Change Requests, the SC may approve the Change Request, consider alternatives, direct the project team to do more research, reject the Change Request and continue the project, or reject the Change Request and request a different change. The SC considers whether the Change Request undermines or supports the project benefits or the project alignment with OCA’s major goals, strategy, budget, and/or direction. vi) Any changes to the Statement of Work or the Service Level Agreement are subject to OCA’s prior written approval. In the absence of any modifications, the performance targets, Service Level Requirements, and measurement intervals in the Service Level Agreement shall apply during the Term of the Agreement.  Deployment Planning – Conduct workshops with OCA and other stakeholders to finalize approach for deploying the solution into production, including possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.  Develop Project Deployment Plan 2) Project Deployment Plan (e.g., transition planning to finalize phased rollout details) – a) Finalized approach for deploying the solution into production including any phasing strategies, site specific considerations, and benefits and risks of strategy: i) Overview of the current environment and considerations for deployment ii) Identification of high-risk transition areas and impact, mitigation strategies, and recommended mitigation actions iii) Any ongoing risks, based on finalization of phasing approach, must be tracked in a risk log iv) Any decisions that impact the schedule must be documented in the project schedule v) Any cutover consideration(s) must be documented in the final Cutover Plan b) Contractor must also provide a finalized project organization chart Activities Work Products  Develop a baseline project schedule to reflect the project timelines, milestones, and deliverables 3) Baseline Project Schedule – Project work plan and schedule, including Xxxxx chart(s) and a project calendar in Microsoft Project that is developed and maintained in accordance with industry best practices. The work plan will reflect any changes from the baseline plan originally agreed to during the project initiation and be updated/published on a weekly basis. The project schedule will include the following components (at a minimum): a) A consolidated view of the activities, activity descriptions, and activity durations assigned to stakeholders and Contractor b) Resources (OCA, other stakeholders, Contractor, and third- party contractors) assigned to each activity and their required level of effort c) A list of all required project deliverables tied to the appropriate project milestones d) Identification of all key project milestones e) Deliverable approval periods compliant with OCA’s Deliverable Expectations Document process as described in the following section Deliverable Expectations Document f) A critical path analysis and reporting process.

Appears in 1 contract

Samples: Master Services Agreement

Project Management Plan. Describes the overall project management approach and schedule throughout the lifecycle of the project. The Project Management Plan will define the following (at a minimum): a) Risk and Issue Management Plans & Logs – Risk and Issue Management Plan, Escalation Plan, and Risk and Issue Register (which must comply with the requirements of the Texas Project Delivery Framework) b) Integrated Change Management Plan – Outlines the process for identifying, evaluating, authorizing, and implementing proposed changes in requirements, schedule, and budget, as well as solution design and acceptance criteria i) For change management, a change is defined as any modification within the scope of or reasonably related to the SOW content including any content in all SOW attachments, such as the Requirements Traceability Matrix. If a potential change is identified by a member of the project team, including the Contractor or OCA (or other internal/external stakeholder), then the change management process outlined below shall be used to initiate a formal Change Request. Similarly, whenever significant deviations are anticipated or reported against implementation processes, schedule or cost, a Change Request is required to re-baseline the project. ii) Change Requests can be initiated at any stakeholder level and may or may not require a formal contract change depending upon its scope. Either OCA or Contractor may initiate a Change Request for a desired process change, Activities Work Products  Develop weekly status reports and schedule ongoing communications for the project  Provide Ongoing Project Management Duties – Provide weekly project plan and schedule updates, weekly status reporting, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the Contractor’s Project Manager shall participate in project Steering Committee meetings and JCIT quarterly meetings as required. depending upon its scope. Either OCA or Contractor may initiate a Change Request for a desired process change, additional funding, and/or a longer timeline as conditions may change on the project over time. iii) During the project, all potential Change Requests must be brought to the Steering Committee (SC) that is composed of key stakeholders from the Texas Judiciary and OCA executive staff and facilitated by the OCA Project Manager. The SC serves as the “Change Control Board” for this project. The Change Request must contain, at a minimum, the description of the change, the schedule to implement the change, and a fixed price based on the number of hours required. iv) The SC is responsible for making decisions on approval/rejection and subsequent prioritization and timing of all Change Requests. v) When the SC reviews Change Requests, the SC may approve the Change Request, consider alternatives, direct the project team to do more research, reject the Change Request and continue the project, or reject the Change Request and request a different change. The SC considers whether the Change Request undermines or supports the project benefits or the project alignment with OCA’s major goals, strategy, budget, and/or direction. vi) Any changes to the Statement of Work or the Service Level Agreement are subject to OCA’s prior written approval. In the absence of any modifications, the performance targets, Service Level Requirements, and measurement intervals in the Service Level Agreement shall apply during the Term of the Agreement.  Deployment Planning – Conduct workshops with OCA and other stakeholders to finalize approach for deploying the solution into production, including possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.  Develop Project Deployment Plan 2) Project Deployment Plan (e.g., transition planning to finalize phased rollout details) – a) Finalized approach for deploying the solution into production including any phasing strategies, site specific considerations, and benefits and risks of strategy: i) Overview of the current environment and considerations for deployment ii) Identification of high-risk transition areas and impact, mitigation strategies, and recommended mitigation actions iii) Any ongoing risks, based on finalization of phasing approach, must be tracked in a risk log iv) Any decisions that impact the schedule must be documented in the project schedule v) Any cutover consideration(s) must be documented in the final Cutover Plan Plan. b) Contractor must also provide a finalized project organization chart Activities Work Products  Develop a baseline project schedule to reflect the project timelines, milestones, and deliverables 3) Baseline Project Schedule – Project work plan and schedule, including Xxxxx chart(s) and a project calendar in Microsoft Project that is developed and maintained in accordance with industry best practices. The work plan will reflect any changes from the baseline plan originally agreed to during the project initiation and be updated/published on a weekly basis. The project schedule will include the following components (at a minimum): a) A consolidated view of the activities, activity descriptions, and activity durations assigned to stakeholders and Contractor b) Resources (OCA, other stakeholders, Contractor, and third- party contractors) assigned to each activity and their required level of effort c) A list of all required project deliverables tied to the appropriate project milestones d) Identification of all key project milestones e) Deliverable approval periods compliant with OCA’s Deliverable Expectations Document process as described in the following section Deliverable Expectations Document f) A critical path analysis and reporting process

Appears in 1 contract

Samples: Master Services Agreement

AutoNDA by SimpleDocs

Project Management Plan. Describes the overall project management approach and schedule throughout the lifecycle of the project. The Project Management Plan will define the following (at a minimum): a) Risk and Issue Management Plans & Logs – Risk and Issue Management Plan, Escalation Plan, and Risk and Issue Register (which must comply with the requirements of the Texas Project Delivery Framework) b) Integrated Change Management Plan – Outlines the process for identifying, evaluating, authorizing, and implementing proposed changes in requirements, schedule, and budget, as well as solution design and acceptance criteria i) For change management, a change is defined as any modification within the scope of or reasonably related to the SOW content including any content in all SOW attachments, such as the Requirements Traceability Matrix. If a potential change is identified by a member of the project team, including the Contractor or OCA (or other internal/external stakeholder), then the change management process outlined below shall be used to initiate a formal Change Request. Similarly, whenever significant deviations are anticipated or reported against implementation processes, schedule or cost, a Change Request is required to re-baseline the project. ii) Change Requests can be initiated at any stakeholder level and may or may not require a formal contract change Activities Work Products Develop weekly status reports and schedule ongoing communications for the project Provide Ongoing Project Management Duties – Provide weekly project plan and schedule updates, weekly status reporting, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the Contractor’s Project Manager shall participate in project Steering Committee meetings and JCIT quarterly meetings as required. depending upon its scope. Either OCA or Contractor may initiate a Change Request for a desired process change, additional funding, and/or a longer timeline as conditions may change on the project over time. iii) During the project, all potential Change Requests must be brought to the Steering Committee (SC) that is composed of key stakeholders from the Texas Judiciary and OCA executive staff and facilitated by the OCA Project Manager. The SC serves as the “Change Control Board” for this project. The Change Request must contain, at a minimum, the description of the change, the schedule to implement the change, and a fixed price based on the number of hours required. iv) The SC is responsible for making decisions on approval/rejection and subsequent prioritization and timing of all Change Requests. v) When the SC reviews Change Requests, the SC may approve the Change Request, consider alternatives, direct the project team to do more research, reject the Change Request and continue the project, or reject the Change Request and request a different change. The SC considers whether the Change Request undermines or supports the project benefits or the project alignment with OCA’s major goals, strategy, budget, and/or direction. vi) Any changes to the Statement of Work or the Service Level Agreement are subject to OCA’s prior written approval. In the absence of any modifications, the performance targets, Service Level Requirements, and measurement intervals in the Service Level Agreement shall apply during the Term of the Agreement.  Deployment Planning – Conduct workshops with OCA and other stakeholders to finalize approach for deploying the solution into production, including possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.  Develop Project Deployment Plan 2) Project Deployment Plan (e.g., transition planning to finalize phased rollout details) – a) Finalized approach for deploying the solution into production including any phasing strategies, site specific considerations, and benefits and risks of strategy: i) Overview of the current environment and considerations for deployment ii) Identification of high-risk transition areas and impact, mitigation strategies, and recommended mitigation actions iii) Any ongoing risks, based on finalization of phasing approach, must be tracked in a risk log iv) Any decisions that impact the schedule must be documented in the project schedule v) Any cutover consideration(s) must be documented in the final Cutover Plan b) Contractor must also provide a finalized project organization chart Activities Work Products  Develop a baseline project schedule to reflect the project timelines, milestones, and deliverables 3) Baseline Project Schedule – Project work plan and schedule, including Xxxxx chart(s) and a project calendar in Microsoft Project that is developed and maintained in accordance with industry best practices. The work plan will reflect any changes from the baseline plan originally agreed to during the project initiation and be updated/published on a weekly basis. The project schedule will include the following components (at a minimum): a) A consolidated view of the activities, activity descriptions, and activity durations assigned to stakeholders and Contractor b) Resources (OCA, other stakeholders, Contractor, and third- party contractors) assigned to each activity and their required level of effort c) A list of all required project deliverables tied to the appropriate project milestones d) Identification of all key project milestones e) Deliverable approval periods compliant with OCA’s Deliverable Expectations Document process as described in the following section Deliverable Expectations Document f) A critical path analysis and reporting process.

Appears in 1 contract

Samples: Master Services Agreement

Project Management Plan. Describes the overall project management approach and schedule throughout the lifecycle of the project. The Project Management Plan will define the following (at a minimum): a) Risk and Issue Management Plans & Logs – Risk and Issue Management Plan, Escalation Plan, and Risk and Issue Register (which must comply with the requirements of the Texas Project Delivery Framework) ). b) Integrated Change Management Plan – Outlines the process for identifying, evaluating, authorizing, and implementing proposed changes in requirements, schedule, and budget, as well as solution design and acceptance criteria criteria. i) For change management, a change is defined as any modification within the scope of or the RFO that is reasonably related to the SOW content including any content in all SOW attachments, such as the Requirements Traceability MatrixActivities Work Products thirty (30) days of contract execution. If a potential change is identified by a member The kickoff meeting will provide an overview of the project teamobjectives, including plans, project scope and schedule, introduce the Contractor or OCA (or other internal/external stakeholder)Contractor’s project team and roles and responsibilities, then the change management process outlined below shall be used to initiate a formal Change Requestand outline project start-up procedures. Similarly, whenever significant deviations are anticipated or reported against implementation processes, schedule or cost, a Change Request is required to re-baseline the project. ii) Change Requests can be initiated at any stakeholder level and may or may not require a formal contract change Activities Work Products  Develop weekly status reports and schedule ongoing communications for the project  Provide Ongoing Project Management Duties – Provide weekly project plan and schedule updates, weekly status reporting, weekly status meetings, risk and issue monitoring, and integrated change management activities. In addition to weekly status meetings, the Contractor’s Project Manager shall participate in project Steering Committee meetings and JCIT quarterly meetings as required. content in all SOW attachments, such as the Requirements Traceability Matrix (RTM). If a potential change is identified by a member of the project team, including the Contractor or OCA (or other internal/external stakeholder), then the change management process outlined below shall be used to initiate a formal Change Request. Similarly, whenever significant deviations are anticipated or reported against implementation processes, schedule or cost, a Change Request is required to re- baseline the project. ii) Change Requests can be initiated at any stakeholder level and may or may not require a formal contract change depending upon its scope. Either OCA or Contractor may initiate a Change Request for a desired process change, additional funding, and/or a longer timeline as conditions may change on the project over time. iii) During the project, all potential Change Requests must be brought to the Steering Committee (SC) that is composed of key stakeholders from the Texas Judiciary and OCA executive staff and facilitated by the OCA Project Manager. The SC serves as the “Change Control Board” for this project. The Change Request must contain, at a minimum, the description of the change, the schedule to implement the change, and a fixed price based on the number of hours required. iv) The SC is responsible for making decisions on approval/rejection and subsequent prioritization and timing of all Change Requests. v) When the SC reviews Change Requests, the SC may approve the Change Request, consider alternatives, direct the project team to do more research, reject the Change Request and continue the project, or reject the Change Request and request a different change. The SC considers whether the Change Request undermines or supports the project benefits or the project alignment with OCA’s major goals, strategy, budget, and/or direction. vi) Any changes to the Statement of Work or the Service Level Agreement are subject to OCA’s prior written approval. In the absence of any modifications, the performance targets, Service Level Requirements, and measurement intervals in the Service Level Agreement shall apply during the Term of the Agreement.  Deployment Planning – Conduct workshops a vision session workshop with OCA OCA, Early Adopter Clerk’s Office, and other stakeholders during the Early Adopter Clerk’s Office implementation to finalize approach for deploying the solution into production, including possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.  Develop Project Deployment Plan 2) Project Deployment Plan (e.g., transition planning to finalize phased rollout details) – a) Finalized approach for deploying the solution into production including any phasing strategies, site specific considerations, and benefits and risks of strategy: i) Overview of the current environment and considerations for deployment deployment. Activities Work Products possible phasing strategies, site specific considerations, and benefits and risks of strategy alternatives.  Develop Project Deployment Plan ii) Identification of high-risk transition areas and impact, mitigation strategies, and recommended mitigation actions actions. iii) Any ongoing risks, based on finalization of phasing approach, must be tracked in a risk log log. iv) Any decisions that impact the schedule must be documented in the project schedule schedule. v) Any cutover consideration(s) must be documented in the final Cutover Plan Plan. b) Contractor must also provide a finalized project organization chart Activities Work Products  Develop a baseline project schedule to reflect the project timelines, milestones, and deliverables 3) Baseline Project Schedule – Project work plan and schedule, including Xxxxx chart(s) and a project calendar in Microsoft Project that is developed and maintained in accordance with industry best practices. The work plan will reflect any changes from the baseline plan originally agreed to during the project initiation and be updated/published on a weekly basis. The project schedule will include the following components (at a minimum): a) A consolidated view of the activities, activity descriptions, and activity durations assigned to stakeholders and Contractor b) Resources (OCA, other stakeholders, Contractor, and third- party contractors) assigned to each activity and their required level of effort c) A list of all required project deliverables tied to the appropriate project milestones d) Identification of all key project milestones e) Deliverable approval periods compliant with OCA’s Deliverable Expectations Document process as described in the following section Deliverable Expectations Document f) A critical path analysis and reporting processchart.

Appears in 1 contract

Samples: Master Services Agreement

Time is Money Join Law Insider Premium to draft better contracts faster.