14-Attachment O - Processes and Procedures.pdf

ATTACHMENT O: PROCESSES AND PROCEDURES

The awarded vendor shall provide comprehensive project management services, employing Agile methodologies to ensure transparent planning, execution, and delivery. TEA has provided Attachment N: Approved Templates and Attachment O: Processes and Procedures for reference and support.

1. Change Management Change Management

The process for handling various types of project changes. The goal is to ensure transparency, minimize disruption, and maintain project control.

Change Management Process

a. Change Request Submission: The vendor submits a formal change request detailing the proposed change, its rationale, impact assessment, and proposed implementation plan.

b. Change Request Review: The TEA project team reviews the change request, assessing its impact on project scope, timeline, budget, and resources.

c. Approval:

o Minor Changes: Minor changes with minimal impact may be approved by the TEA project manager.

o Major Changes: Major changes with significant impact will be reviewed and approved by the Change Control Board (CCB), which includes representatives from both TEA and the vendor.

o Critical Changes: Critical changes affecting project scope, budget, or timeline may require additional approval from the Steering Committee or IT Governance.

d. Change Implementation: Upon approval, the vendor implements the change according to the agreed-upon plan.

e. Change Verification: The TEA project team verifies the successful implementation of the change and its adherence to the approved requirements.

f. Change Closure: The change request is formally closed, and documentation is updated to reflect the change.

Types of Changes and Approval Processes:

Budget Changes o Use a Request for Budget Revision (RBR) form to propose any changes to the project budget.

This aligns with our formal agency process and facilitates tracking and approval.

Contractual Changes o For changes affecting terms, scope, schedule, or budget outlined in the contract, a formal Contract Amendment is required. This adheres to our agency's established procedures.

Infrastructure Changes o All application infrastructure modifications are managed through the Infrastructure Change

Control Board (ICCB) according to formal IT procedures.

Technology Changes o All technology and changes to existing technology require formal review by TEA’s Technology Review Committee (TRC).

IT Governance o All significant project requests or new request for IT resources, technology shifts, security metrics, security recommendations, security plans, high impact risks to IT or Agency stakeholders, new initiatives, software or hardware procurement requests, service level agreement reviews, and application team metrics must be reviewed and approved by IT Governance (ITG).

Project Schedule, Scope Changes, Release Scope Changes, Requirements Changes, Resource Changes, Sprint Scope Changes

i. Submit all proposed changes to the project manager in writing.

ii. The project team will then review the change request in the project team’s Change Control

Board (CCB) and assess its impact on project scope, resources, schedule, and risks.

iii. Depending on the significance of the change, it may be further reviewed by the Steering

Committee.

iv. A final decision will be made, documented, and communicated to stakeholders.

2. Issue Management The information below outlines the process for managing project issues, ensuring timely identification, resolution, and minimal disruption to project goals. It incorporates both established IT practices.

Issue Management Process

a) Issue Identification and Reporting: Any team member (TEA or vendor) can report an issue through the designated issue tracking tool. The report should include a clear description, potential impact, and relevant details.

b) Issue Triage: The project manager assesses the issue's severity and urgency, assigning it a priority level (Highest, High, Medium, Low, Lowest).

c) Issue Assignment and Resolution:

o Highest/High Priority: The project manager assigns the issue to the appropriate team member for immediate investigation and resolution. Regular updates are provided to TEA.

o Medium/Low Priority: The issue is added to the backlog and addressed according to its priority and the team's capacity.

d) Issue Tracking and Communication: All issue details, status updates, and resolution steps are documented in the issue tracking tool. Regular communication is maintained with TEA regarding the progress of issue resolution.

e) Issue Closure: An issue is closed when the root cause is addressed, the solution is implemented and verified, and the issue no longer poses a risk to the project.

Resources:

• Project Team: All project team members are responsible for identifying and reporting potential issues.

• Project Manager: Leads the issue management process, assigns resources, and tracks progress towards resolution.

• Issue Tracking Tool: A centralized platform must be used to report, track, and manage issues.

Methods and Tools:

• Issue Reporting:

o Team members can report issues verbally during meetings, through emails, or directly in the issue tracking tool.

o The report should clearly describe the issue, its potential impact, and any relevant details

(screenshots, error messages).

• Issue Analysis:

o The project manager, along with relevant team members, will analyze each reported issue. This involves:

Identifying the root cause of the problem.

Assessing the severity and potential impact on project schedule, budget, scope, or quality.

Estimating the effort required for resolution.

• Issue Prioritization:

o A prioritization matrix will be used to categorize issues based on severity (impact) and urgency

(time sensitivity). This helps allocate resources and address critical issues first.

• Issue Resolution:

o The project manager assigns ownership for each issue and establishes a clear resolution plan with deadlines.

o The resolution plan may involve:

Troubleshooting and implementing corrective actions.

Seeking assistance from subject matter experts.

Escalating to stakeholders or external vendors if necessary.

Tracking and Closure:

• Issue Tracking Tool: All reported issues, their status (new, assigned, in progress, resolved), resolution steps, and communication logs will be documented in Jira. This ensures transparency and facilitates progress monitoring.

• Closure Criteria:

o An issue is considered closed when:

The root cause has been addressed, and a solution has been implemented.

The issue no longer poses a threat to project goals.

The resolution is verified and documented.

o The project manager confirms closure and updates the issue status in the tracking tool.

3. Risk Management The project team will identify risks by carefully reviewing project uncertainties, external dependencies that could lead to potential failure or delay of project and use techniques including analyzing assumptions, and brainstorming.

Risk Management Process

a) Risk Identification: The project team (TEA and vendor) collaboratively identifies potential risks through brainstorming, risk assessment workshops, and review of project documentation.

b) Risk Analysis: Each identified risk is analyzed to determine its probability of occurrence and potential impact on the project. Risks are categorized as Acceptable, Undesirable, or Unacceptable based on their exposure score.

c) Risk Mitigation Planning: For Undesirable and Unacceptable risks, mitigation plans are developed, outlining specific actions to reduce the probability or impact of the risk.

d) Risk Monitoring and Review: Risks are regularly monitored and reviewed throughout the project lifecycle.

The risk register is updated with any changes in risk status or mitigation plans.

e) Risk Reporting: The project manager provides regular risk reports to the TEA project team and stakeholders, highlighting key risks, mitigation strategies, and overall risk exposure.

f) Risk Escalation: Unacceptable risks or risks that exceed defined thresholds are escalated to the Steering Committee or IT Governance for further review and decision-making.

Risk Analysis

Risk Analysis Description

The Vendor project manager will work with team to

• Determine the probability of the risk occurring, impact of the risk occurring and identify unacceptable and undesirable risks that need treatment.

• Measure and score for each Risk:

o Probability (Likely = 1, Occasionally = .75, Seldom = .50, Unlikely = .25) - Probability that this risk will manifest o Impact (Extensive/Widespread = 10, Significant/Large =

8, Moderate/Limited = 6, Minor/Localized = 2) - The magnitude of impact should the risk happen.

• Calculate Exposure by multiplying Probability and Impact to create a score between 1 and 10.

Scales Description

Risk exposure score, Risk priority, Risk exposure

Risk Threshold Values Description

Risk Response Strategies

The project risks identified will be assessed and prioritized by completing an analysis of each Risk. Based on the analysis the following mitigation steps will be taken:

• Avoid risk - Change project plans (scope, schedule, quality, costs, objectives) to prevent the risk.

• Control risk - Reduce impact and/or likelihood of the risk by taking some defined steps or actions.

• Accept risk - Accept the likelihood and/or impact and take no additional actions.

• Transfer risk - Outsource all or part of management of the risk to third parties.

Risk Monitoring and Control

Risk Tracking

Technology related project risks are tracked using the IT JIRA Risk register to monitor the status of the implemented treatments and to ensure their permanent effectiveness. The process will include the following steps:

• Track and test treatment options tested for undesirable and unacceptable risks

• Frequently deciding if original or residual risks should continue to be accepted

• Adjustments to scope, schedule, or budget as needed and approved

• Continuously monitoring for additional risks

Risk Reporting

The overall status of risk management is communicated to all relevant stakeholders at least every month and more frequently, as needed.

• All risks with an exposure of Unacceptable or Undesirable need to be reviewed by the Steering Committee.

• All technology risks with Unacceptable risk exposure must be reviewed by ITG.

4. Escalation Management

Purpose: To provide a structured approach for resolving project issues promptly and effectively, minimizing disruptions and ensuring timely communication between the Texas Education Agency (TEA) and the Vendor.

Level 1: Initial Communication and Resolution

• Timeline: Within one (1) business day of issue identification.

• Action: The TEA or Vendor representative who identifies an issue communicates it directly to their designated Point of Contact (POC) on the other team.

• Resolution Goal: The POCs collaborate to understand the issue, explore potential solutions, and aim to resolve the issue within the initial timeline.

• Documentation: Both POCs document the issue, discussions, and any agreed-upon resolutions in the project's issue tracking system.

Level 2: Project Manager Escalation

• Escalation Trigger: If the issue is not resolved within one (1) business day at Level 1, or if the issue's severity warrants immediate escalation.

• Timeline: Within two (2) business days of escalation.

• Action: The POC escalates the issue to their respective Project Manager (PM). The PMs from both teams convene a joint meeting, involving the relevant POCs.

• Resolution Goal: The PMs facilitate a focused discussion to analyze the issue, explore additional solutions, and aim to reach a resolution within the escalated timeline.

• Documentation: Detailed meeting minutes, including the agreed-upon resolution and any action items, are recorded in the issue tracking system.

Level 3: Executive Escalation

• Escalation Trigger: If the issue remains unresolved within two (2) business days at Level 2, or if the issue significantly impacts project deliverables or timelines.

• Timeline: Within three (3) business days of escalation.

• Action: Either PM can escalate the issue to their respective executive management (TEA contract management or Vendor leadership). An executive-level meeting is convened, including the PMs and relevant POCs.

• Resolution Goal: Executive management provides guidance and facilitates a resolution within the escalated timeline, considering the broader project context and potential impacts.

• Documentation: Formal meeting minutes, outlining the final resolution and any resulting actions, are distributed to all project stakeholders.

General Guidelines

• Timelines: The timelines specified for each level are business days and begin upon the initial reporting or escalation of the issue.

• Communication: Throughout the escalation process, both parties will maintain open and transparent communication, providing timely updates and adhering to agreed-upon timelines.

• Good Faith Effort: Both TEA and the Vendor will make a good faith effort to resolve issues at the lowest possible level before escalating.

• Confidentiality: All discussions and documentation related to escalated issues will be treated as confidential, shared only with relevant personnel involved in the resolution process.

5. Knowledge Transfer Knowledge Transfer Plan o At the beginning of the project, the Vendor will create a detailed Knowledge Transfer Plan outlining the scope, objectives, timeline, and specific topics to be covered. This plan will be reviewed and approved by TEA.

Knowledge Transfer Sessions o Regular knowledge transfer sessions will be conducted throughout the project lifecycle, with a minimum frequency of:

1. Weekly: During active development phases.

2. Bi-weekly: During testing and deployment phases.

3. Monthly: During post-launch and maintenance phases.

4. The format of these sessions can include presentations, demonstrations, hands-on exercises, Q&A sessions, and code walkthroughs.

Documentation o The Vendor will maintain comprehensive documentation, including:

1. Technical Documentation: Detailed architecture diagrams, API specifications, code documentation, deployment instructions, and troubleshooting guides.

2. User Documentation: User manuals, training materials, FAQs, and how-to guides.

3. Process Documentation: Standard operating procedures (SOPs) for system maintenance, updates, and incident response.

Knowledge Transfer Checklist o A checklist will be used to track the completion of knowledge transfer activities and ensure all critical knowledge areas are covered.

Assessment and Sign-off:

o At the end of each knowledge transfer session, TEA personnel will assess their understanding of the transferred knowledge. A formal sign-off process will be established to confirm successful knowledge transfer for each topic or module.