4-Attachment E - Task, Activity, Deliverable, and Budget Plan.pdf

ATTACHMENT E: TASK, ACTIVITY, DELIVERABLE, AND BUDGET PLAN

* The information in this template is for EXAMPLE ONLY. The following table contains the minimum required deliverables and the expected delivery schedule for those deliverables. TEA expects vendors to include additional deliverables relative to the contents of their proposed services.

Payment Milestones Tied to Deliverables

Payment Milestone

Milestone Name Included Deliverables

Acceptance Summary Payment Amount

Budget

PM-01 Project Initiation & Planning Complete

D-01.1.01

D-01.1.02

D-01.1.03

D-01.1.04

D-01.1.05

D-01.1.06

D-02.1.01

D-02.1.02

Deliverable acceptance criteria met and accepted;

Project governance plans accepted, Roadmap created, Sprint 0 readiness approved; TEA authorizes development start

5%

PM-02 Discovery, UX, & Requirements Baseline

D-02.1.01

D-02.1.02

D-03.1.01

D-03.1.02

D-03.1.03

D-04.1.01

D-04.1.02

D-04.1.03

D-04.1.04

D-04.1.05

D-04.1.06

D-05.1.01

D-05.1.02

D-05.1.03

D-05.1.04

Deliverable acceptance criteria met and accepted;

Inventories delivered;

Information Architecture, UX, Business Requirements, Epics, Backlog, and user stories baselined and approved

10%

D-05.1.05

PM-03 Technical Architecture & Dev Readiness

D-02.1.01

D-02.1.02

D-06.1.01

D-06.1.02

D-06.1.03

D-06.1.04

D-06.1.05

D-12.1.01

Deliverable acceptance criteria met and accepted;

Integration plan, architecture, coding standards, SCM, and access standards approved

10%

PM-04 OneApp Grant Management Delivered

D-02.1.01

D-02.1.02

D-05.1.02

D-05.1.03

D-05.1.04

D-05.1.05

D-07.1.01

D-07.1.04

D-07.1.05

D-07.1.06

D-07.1.07

D-07.1.08

D-08.1.01

D-08.1.02

D-08.1.03

D-08.1.04

D-08.1.05

D-08.1.06

Deliverable acceptance criteria met and accepted;

OneApp Grant Management fully functional end-to-end, including required TEA integrations, dashboards, reports, audit-logs, and data retention requirements; tested with zero Highest/High defects;

security and accessibility conditions satisfied;

accepted in the production environment.

30%

D-08.1.07

D-08.1.08

D-08-1.09

D-08.1.10

D-08.1.11

D-09.1.02

D-09.1.03

D-09.1.04

D-10.1.01

D-10.1.02

D-10.1.03

D-10.1.04

D-10.1.05

D-10.1.06

D-11.1.01

D-12.1.02

D-12.1.03

D-12.1.04

D-12.1.05

D-12.1.06

D-12.1.07

D-12.1.08

D-12.1.09

PM-05 OnePlan Planning Modules Delivered

D-02.1.01

D-02.1.02

D-05.1.02

Deliverable acceptance criteria met and accepted;

OnePlan modules fully functional end-to-end, including required TEA

20%

D-05.1.03

D-05.1.04

D-05.1.05

D-07.1.02

D-07.1.04

D-07.1.05

D-07.1.06

D-07.1.07

D-07.1.08

D-08.1.01

D-08.1.02

D-08.1.03

D-08.1.04

D-08.1.05

D-08.1.06

D-08.1.07

D-08.1.08

D-08-1.09

D-08.1.10

D-08.1.11

D-09.1.02

D-09.1.03

D-09.1.04

D-10.1.01

D-10.1.02

D-10.1.03

D-10.1.04 integrations, dashboards, reports, audit-logs, and data retention requirements; tested with zero Highest/High defects;

security and accessibility conditions satisfied;

accepted in the

D-10.1.05

D-10.1.06

D-11.1.01

D-12.1.02

D-12.1.03

D-12.1.04

D-12.1.05

D-12.1.06

D-12.1.07

D-12.1.08

D-12.1.09

PM-06 Performance Management Modules Delivered

D-02.1.01

D-02.1.02

D-05.1.02

D-05.1.03

D-05.1.04

D-05.1.05

D-07.1.03

D-07.1.04

D-07.1.05

D-07.1.06

D-07.1.07

D-07.1.08

D-08.1.01

D-08.1.02

D-08.1.03

D-08.1.04

Deliverable acceptance criteria met and accepted;

Performance Management modules fully functional end-to-end, including required TEA integrations, dashboards, reports, audit-logs, and data retention requirements;

tested with zero Highest/High defects;

security and accessibility conditions satisfied;

accepted in the

10%

D-08.1.05

D-08.1.06

D-08.1.07

D-08.1.08

D-08-1.09

D-08.1.10

D-08.1.11

D-09.1.02

D-09.1.03

D-09.1.04

D-10.1.01

D-10.1.02

D-10.1.03

D-10.1.04

D-10.1.05

D-10.1.06

D-11.1.01

D-12.1.02

D-12.1.03

D-12.1.04

D-12.1.05

D-12.1.06

D-12.1.07

D-12.1.08

D-12.1.09

PM-07 Stabilization & Project Close-Out

D-02.1.01

D-02.1.02

Deliverable acceptance criteria met and accepted;

90-day stabilization

15%

D-05.1.03

D-05.1.04

D-05.1.05

D-11.1.01

D-11.1.02

D-11.1.03 complete; Analytics delivered; All High and Highest defects resolved;

Final Acceptance

Total 100%

Deliverables

# Deliverable Acceptance Criteria – The Vendor shall meet the defined acceptance criteria as agreed to by the TEA Contract Manager

Sprint

D-01.1.01 Project Kickoff 1. Project Overview and Objectives, Scope, schedule, budget baseline, roles responsibilities, communication plan, initial risk register, dependencies, assumptions, project acceptance criteria, next steps

2. TEA acceptance of all required Project Kick-Off artifacts

D-01.1.02 Detailed Project Plan

1. Phased Timeline, dependencies, milestones, and deliverables for all scope, following SDLC, and agile project standards, agile cadence, agile ceremonies, and resource assignments aligned with sprint capacity

2. TEA accepts the project plan meets acceptance criteria

D-01.1.03 Risk Register & Mitigation Plans

1. Identified risks, probability, impact, contingency plans; mitigation and escalation strategies, updated weekly

2. Risk register documented in Jira, mitigation strategies approved, escalation and review cadence established

D-01.1.04 Change Request Impact Assessments

1. Scope, schedule, costs, and risk impact; submitted for TEA Contract Manager approval prior to execution.

2. Change impact analysis completed, documented, and approved prior to execution

D-01.1.05 Project Roadmap

1. Project roadmap is up to date using Jira Software showing epics with due dates, stories with target sprints identified, requirement due dates set, expected testing start date for each work item, expected UAT start date, BA assignee, developer assignee, dev test assignee, QA assignee, and UAT assignee. Dependencies (blocking and blocked by) mapped between work items.

2. Roadmap finalized in Jira, aligned to milestones, releases, and approved delivery sequence.

D-01.1.06 Sprint 0 1. Establish a shared understanding of scope, requirements, governance, technical architecture, and delivery approach;

2. Configure all required environments and tools; and ensure the project is fully ready to enter iterative development.

D-02.1.01 Weekly Status Reports

1. Progress against planned sprint goals, milestones, and deliverables

2. Completed tasks and in-progress work for the reporting period

3. Identified risks, issues, and blockers, including severity and mitigation actions

4. Decisions made during the week, including decision owner and date

5. Action items with assigned owners, due dates, and status

6. Status of open defects, including severity, aging, and expected resolution timelines

7. Validated assumptions and constraints

8. Upcoming milestones, deliverables, and dependencies

9. Resource utilization and high-level budget status

10. Information is consistent with data in TEA-mandated tools (Jira, Microsoft365, Zephyr Scale, Modern Requirements, etc)

11. All referenced work items, risks, defects, and decisions are traceable to TEA-managed systems

12. Report is submitted using the agreed TEA-approved format

13. Report is stored in the project’s document repository

14. Feedback for any omissions or inaccuracies are incorporated into the report

15. Weekly status reports delivered on time, complete and accepted for reporting period.

16. TEA approval required D-02.1.02 Monthly

Performance & SLA Reports

1. Report is delivered by the fifth (5th) business day of the following month

2. Sprint-level KPIs including sprint velocity, sprint burndown, sprint goal completion rate, sprint success rate (definition of done compliance)

3. Defect density and trend analysis

4. Cumulative Flow Diagram with analysis on where bottlenecks are in the process and mitigations to resolve those over the next month; input on results from prior month mitigations

5. Release burn-up – are we on schedule

6. Lead time and cycle time metrics

7. Post-launch KPIs (when applicable), including user satisfaction and application performance

8. Complete reporting of all SLA metrics defined in the SOW

9. Explicit identification of any SLA failures

10. Calculation of applicable service credits or deductions

11. Root cause analysis (RCA) and corrective action plans for each SLA deviation

12. Comparison of actual performance against defined targets and acceptable variance, identification of trends, risks, and systemic issues

13. Clear, actionable recommendations for improvement with owner and timeline for completion

14. Metrics are sourced from TEA-approved monitoring and reporting tools

15. Underlying data is auditable and available to TEA upon request

16. Updates on Corrective Action Plans, where appropriate, to address cure notices

17. Report stored in project’s documentation repository

18. Corrections are made and resubmitted prior to acceptance

19. Monthly KPI and SLA performance report accepted with corrective actions documented

20. Customization Register

21. TEA confirms the report meets expectations

Submission of an incomplete or late report constitutes non-acceptance and may trigger contractual deductions and invoice rejection

D-03.1.01 Application Inventory Audit

1. Comprehensive Inventory: A detailed inventory is created for all existing application components, including codebase, libraries, frameworks, configurations, and dependencies.

2. Categorization: Application components are categorized based on their type, function, and relevance to the project's goals.

3. Versioning: Current versions of each component are documented, along with any known compatibility issues or dependencies.

4. Gap Analysis: Potential gaps or missing components necessary for the project's success are identified and documented.

5. Feedback addressed and confirmed the deliverable meets goals and objectives on clarity, completeness, usability, and alignment with research findings.

6. Application inventory completed, gaps identified, and audit report accepted.

7. Final report is integrated into the project’s documentation repository.

D-03.1.02 Document Repository Inventory

1. Comprehensive Inventory: A detailed inventory is created for all existing documents related to the application, including requirements documents, design specifications, user manuals, test plans, and any other relevant documentation.

2. Categorization: Documents are categorized based on their type, purpose, and audience.

3. Version Control: Current versions of each document are documented, ensuring traceability, and avoiding confusion.

4. Gap Analysis: Missing or outdated documentation is identified, along with potential areas for improvement in content, organization, or accessibility.

5. Document inventory completed, gaps identified, and repository audit accepted.

D-03.1.03 Inventory & Audit Final Report

1. A comprehensive report is created, documenting the results of the inventory and audit process.

2. The report includes detailed inventories for both the application and document repository, along with identified gaps and potential improvements.

3. The report is shared with TEA stakeholders for review and discussion.

4. Feedback addressed and confirmed the deliverable meets goals and objectives on clarity, completeness, usability, and alignment with research findings.

5. Consolidated inventory and audit report approved with improvement recommendations

6. Final report is integrated into the project’s documentation repository.

D-04.1.01 Information

Architecture (IA) Diagram

1. Comprehensive Representation: A detailed information architecture (IA) diagram is created, visually representing the hierarchical structure and organization of the application's content, features, and functionalities.

2. Clarity and Detail: The diagram clearly depicts the relationships between different content elements, sections, and pages within the application.

3. User-Centered Design: The IA diagram is designed with the user in mind, ensuring a logical and intuitive structure that aligns with user expectations and mental models.

4. Research and Discovery Alignment:

The IA diagram reflects the findings and insights gathered during the research and discovery phase, addressing user needs and preferences.

5. The IA diagram and sitemap are reviewed and approved by TEA stakeholders, ensuring alignment with project goals, user needs, and branding guidelines.

6. Feedback is collected and incorporated into the final versions of the diagrams and stored in the project’s document repository.

7. Information architecture diagram reviewed, updated, and formally approved

8. IA Diagram feedback addressed and confirmed the diagram meets goals and objectives on clarity, completeness, usability, and alignment with research findings.

D-04.1.02 Application Sitemap

1. Hierarchical Structure: A sitemap is provided, outlining the hierarchical structure of the application's pages and their relationships, complementing the IA diagram.

2. Page Metadata: The sitemap includes relevant metadata for each page, such as page titles, URLs, and descriptions.

3. Navigation Paths: The sitemap clearly illustrates the primary navigation paths and potential user flows through the application.

4. Application sitemap feedback addressed and confirmed the sitemap meets goals and objectives on clarity, completeness, usability, and alignment with research findings.

5. Application sitemap finalized, validated, and approved for navigation structure.

6. The final versions of the diagrams and stored in the project’s document repository.

D-04.1.03 Navigation & IA Workshop Outputs

1. Intuitive Navigation: The IA diagram and sitemap are designed to facilitate intuitive and seamless navigation for users, minimizing friction and maximizing usability.

2. Clear Pathways: Primary user goals and tasks are supported by clear navigation pathways, ensuring users can easily find and access the information or functionality they need.

3. Accessibility: Navigation elements are designed to be accessible to users with disabilities, adhering to WCAG guidelines.

4. A collaborative workshop is conducted with TEA stakeholders and the vendor's UX/UI team to refine the sitemap and navigation structure.

5. The workshop focuses on optimizing user flows, addressing potential pain points, and ensuring the navigation aligns with user expectations and mental models.

6. Outcomes of the workshop are documented and reflected in the updated IA diagram and sitemap.

7. The vendor will conduct the application navigation workshop with TEA stakeholders, incorporating feedback and refining the sitemap.

8. Navigation workshop completed; IA updates incorporated and approved.

9. Feedback is collected and incorporated into the final versions and stored in the project’s document repository.

D-04.1.04 Interactive Wireframes

1. Low-Fidelity Prototypes: The vendor will create low-fidelity interactive wireframes and prototypes for key application pages, functionalities, and sections.

2. Key Elements: These prototypes will focus on the core user flows, navigation structure, content layout, and basic interactions.

3. Tooling: Prototypes will be created using a suitable prototyping tool (e.g., Figma) that facilitates easy sharing and collaboration, and is compatible with TEA's existing tools and processes.

4. User Needs Addressed: The wireframes and prototypes will effectively address user needs and requirements as outlined in the project's functional specifications and user stories, ensuring that the proposed design aligns with user expectations.

5. The approved wireframes and prototypes, along with associated documentation (e.g., user flows, task scenarios, user testing report), will be stored in TEA's designated requirements management tool for future reference and traceability.

6. The vendor will ensure that the files are properly organized, versioned, and labeled within the tool.

7. TEA reviews the wireframes and prototypes, providing feedback on usability, functionality, accessibility, and adherence to project requirements.

8. Interactive wireframes approved following usability review and feedback incorporation.

9. The vendor will iterate on the prototypes based on feedback, incorporating user testing insights, and obtain final approval from TEA.

D-04.1.05 User Testing Report

1. Participant Selection: The vendor and TEA will collaborate to identify and recruit a diverse group of representative users from the target audience for testing, ensuring representation of various demographics, skill levels, and accessibility needs.

2. Moderated Testing: The vendor will conduct moderated user testing sessions where participants interact with the prototypes, complete tasks, and provide feedback. Sessions will be recorded for future reference and analysis.

3. Observation and Feedback Collection:

A TEA-assigned Business Analyst will observe the testing sessions, document user interactions and feedback, and collaborate with the vendor to analyze results. Detailed notes and findings will be compiled in a user testing report.

4. The vendor will conduct user testing sessions, documenting findings and observations in the user testing report.

5. The TEA Product Owner or designated representative(s) will actively participate in testing sessions, analyze feedback, and collaborate with the vendor on potential design improvements.

6. Design changes based on user feedback will be implemented and presented to TEA for final approval.

7. User testing completed; findings documented and design updates approved.

8. Upon successful completion of user testing and feedback incorporation, the final approved wireframes, prototypes, and user testing report will be stored in TEA's requirements management tool.

D-04.1.06 High-Fidelity

Visual Design Mockups

1. Interactive Mockups: The vendor will create high-fidelity mockups for all key screens and user flows within the application, ensuring they are interactive (clickable) to demonstrate user journeys and interactions.

2. TEA Branding Adherence: Mockups will adhere to TEA's branding guidelines, including color palette, typography, logo usage, imagery, iconography, and overall look and feel.

3. Meets IT Style Guide requirements

4. WCAG Compliance: Mockups will incorporate accessibility considerations from the outset, ensuring compliance with most current WCAG criteria, including sufficient color contrast, clear focus states, and accessible navigation elements.

5. Presentation: The vendor will present the mockups to TEA stakeholders in a formal review session, explaining design choices, gathering feedback, and addressing any questions.

6. Feedback and Iteration: TEA will have 10 business days to review the high-fidelity mockups and provide feedback, addressing visual design, adherence to TEA branding, and accessibility considerations. The vendor will iterate on the mockups based on TEA's feedback until final approval is granted.

7. High-fidelity designs approved meeting branding, accessibility, and usability standards

8. Final Approval: Upon approval of the final mockups, the vendor will provide the finalized web branding guidance document, incorporating any feedback and adjustments made during the review process.

9. Updates and Revisions: The vendor will maintain the mockups and branding guidance throughout the project, making updates as needed based on feedback or design changes, ensuring the documentation remains accurate and up to date.

D-05.1.01 Business Requirements

1. Comprehensive Overview: A comprehensive set of Business Requirements (BRs) is provided, detailing the high-level needs, goals, and outcomes the application must address to be considered successful from the Product Owner's perspective.

2. Clear Articulation: The BRs clearly describes the problem or opportunity the application aims to solve, the target users and their needs, and the desired business value and benefits.

3. Scope Definition: The BRs defines the scope of the project, including what is in scope and out of scope, to ensure a shared understanding between the vendor and TEA.

4. Constraints and Assumptions: Any known constraints (e.g., budget, timeline, technology limitations) and assumptions made during the requirements gathering process are explicitly stated.

5. The approved Business Requirements is stored in TEA's designated requirements management tool (Modern Requirements) for traceability and reference throughout the project lifecycle.

6. The requirements are version-controlled and linked to other relevant artifacts, such as Customization Register, user stories, design documents, and test cases.

7. The BRs will be refined iteratively based on feedback and further clarification until it is fully understood and approved.

8. Business requirement finalized, approved, and baselined in requirements repository.

9. Upon successful completion of the review process and incorporation of feedback, the TEA Product Owner will provide written approval of the final Business Requirements.

10. The final versions of the documents are delivered in appropriate formats (e.g., PDF, image files) and integrated into the requirements repository.

D-05.1.02 Requirements

Workshop Documentation

1. Collaborative workshops are held with the TEA Product Owner, relevant stakeholders, and the vendor's business analyst(s) to elicit, refine, and validate the business requirements.

2. Workshops utilize effective techniques (e.g., brainstorming, storyboarding, use case analysis) to gather comprehensive requirements.

3. Workshop outcomes are documented and incorporated into the BRs.

4. Dedicated meetings are held to walk through the BRs with TEA project stakeholders, ensuring a shared understanding of the requirements and soliciting feedback.

5. Feedback is collected, analyzed, and incorporated into the BRs, as necessary.

6. Detailed notes from requirements workshops and walk-through meetings are documented and shared with relevant stakeholders.

7. Notes include decisions made, action items, open questions, and any conflicting viewpoints that need resolution.

8. The BRs are updated to reflect the outcomes of these discussions.

9. Requirements workshops completed;

documentation finalized and accepted

10. The vendor will participate in requirements workshops and walk-through meetings with the TEA Product Owner and stakeholders.

D-05.1.03 Epics 1. A comprehensive plan is developed, outlining the following for each epic:

• Breakdown into smaller user stories with clear acceptance criteria

• Resource allocation (team members, skills required)

• Estimated effort and duration for each user story

• Proposed timeline for completing the epic, including start and end dates

2. Dependencies between epics and user stories are identified and accounted for in the timeline.

3. The plan is realistic, achievable, and aligned with the project's overall timeline and budget constraints.

4. A comprehensive list of high-level business requirements is provided, clearly articulated as epics.

5. Each epic represents a significant body of work that can be broken down into smaller user stories.

6. The list is prioritized based on the business value, urgency, or dependencies of each epic.

7. The prioritization process is transparent and documented, involving input from relevant TEA stakeholders.

8. Each epic includes a clear and concise description of its scope and objectives, outlining the desired outcome or functionality from the user's perspective.

9. A detailed rationale is provided for each epic's priority, explaining the reasons behind its position in the prioritized list.

10. Rationale may include factors such as business impact, user needs, technical feasibility, or regulatory requirements.

11. Detailed notes and decisions from requirements workshops are documented and shared with TEA stakeholders.

12. Documentation includes a clear record of discussions, agreements, and any outstanding questions or concerns.

13. Feedback will be provided on the clarity, completeness, prioritization, and feasibility of the plan.

14. The vendor will iterate on the plan based on feedback and resubmit for approval.

15. The epics are approved in TEAs project management tool (Jira Software)

16. Epics defined, prioritized, estimated, and approved in Jira.

17. Workshop outcomes are reflected in the refined epic descriptions and prioritization.

18. Throughout the project, the vendor and TEA will collaborate to track progress against the epic plan, adjust timelines and resources as needed, and ensure that the project stays on track to deliver the desired outcomes.

D-05.1.04 Product Backlog 1. Comprehensive List: A prioritized list of user stories is provided, encompassing both functional and non-functional requirements of the application.

2. TEA Best Practices: User stories are written in accordance with TEA's established guidelines for user story format, content, and prioritization.

3. Two Sprints of Work: The backlog maintains a minimum of two sprints' worth of work that is prioritized and refined at all times, ensuring a continuous flow of development-ready items.

4. Acceptance Criteria: Each user story includes clear and measurable acceptance criteria that define the conditions for successful completion.

5. Estimation: User stories are estimated in collaboration with the development team, providing a basis for sprint planning and tracking progress.

6. Dependencies: Dependencies between user stories are identified and documented, ensuring a logical development sequence.

7. Clarity and Detail: User stories are refined to a level of detail that allows the development team to understand the requirements and estimate the effort accurately.

8. The product backlog is reviewed and approved by the TEA Product Owner, ensuring that it aligns with the project's scope, priorities, and strategic goals.

9. The backlog is understood and agreed upon by all TEA project stakeholders.

10. Regular backlog refinement sessions are held between the vendor and the TEA Product Owner, involving relevant stakeholders as needed.

11. Sessions focus on:

12. Reviewing and refining existing user stories

• Adding new user stories

• Adjusting priorities based on changing needs

• Ensuring the backlog maintains a minimum of two sprints' worth of ready work

• As needed, dedicated meetings are held to clarify specific user stories, resolve ambiguities, and ensure a shared understanding between the vendor and TEA stakeholders.

13. Outcomes of these meetings are documented and reflected in the updated backlog.

14. Detailed notes from backlog refinement and user story clarification meetings are documented and shared with relevant stakeholders.

15. Notes include decisions made, action items, and any open questions or concerns.

16. The backlog is updated to reflect the outcomes of these discussions.

17. The vendor will participate in regular backlog refinement sessions with the TEA Product Owner and stakeholders.

18. The backlog will be continuously refined throughout the project, with a focus on preparing user stories for upcoming sprints.

19. The backlog will be refined and ready before the start of each sprint.

20. Product backlog refined, prioritized, and approved meeting Definition of Ready

21. Before the start of each sprint, the TEA Product Owner will provide written approval of the refined backlog, confirming that it meets their expectations and priorities for the upcoming sprint.

22. Two sprints worth (based on expected team capacity) of backlog are decomposed and meet the Definition of Ready (DoR).

D-05.1.05 User Stories 1. Each user story follows a standard format (e.g., "As a [role], I want [goal] so that [reason]").

2. Stories are written in clear, concise language that is easily understood by both technical and non-technical stakeholders.

3. Stories focus on user needs and desired outcomes, rather than technical implementation details.

4. Each user story includes well-defined acceptance criteria that outline the specific conditions that must be met for the story to be considered complete.

5. Acceptance criteria are measurable, testable, and clearly define the expected behavior of the application.

6. User stories are reviewed and approved by TEA project stakeholders, ensuring that they accurately reflect user needs and align with project goals.

7. Feedback and revisions are incorporated as needed before stories are finalized.

8. Approved user stories are stored in TEA's designated requirements management tool for traceability and reference throughout the development process.

9. Stories are linked to relevant design documents, test cases, and code implementations.

10. User stories are prioritized and assigned to development sprints.

11. User stories approved with acceptance criteria and sprint readiness confirmed.

12. Developers work on user stories during each sprint, ensuring that completed stories meet the defined acceptance criteria.

13. At the end of each sprint, the vendor will demonstrate the completed user stories to TEA stakeholders, verifying that they meet the acceptance criteria.

14. Upon successful completion of all sprints and verification of user story acceptance criteria, TEA will provide written approval to confirm acceptance.

D-06.1.01 Integration Plan 1. API Integrations: The plan clearly outlines all API integrations required within the application, including:

• Internal TEA APIs

• Third-party APIs

• Custom-built APIs

• Data Flow: The plan details the flow of data between the application and integrated systems, including data formats, protocols, and any transformations required.

3. Authentication and Authorization: The plan specifies the authentication and authorization mechanisms used for each API integration, ensuring secure data exchange.

4. Error Handling: The plan defines error handling strategies for API failures, ensuring graceful recovery and minimal disruption to the user experience.

5. Security Considerations: The plan addresses security risks associated with API integrations, such as data breaches, unauthorized access, and injection attacks. Mitigation strategies for each identified risk are outlined.

6. The integration plan is documented in detail, including all API specifications, data flow diagrams, security considerations, and error handling procedures.

7. Integration plan finalized, risks assessed, and technical approach approved.

8. The document is version-controlled and maintained throughout the project, reflecting any changes or updates.

9. Feedback is collected and incorporated into the final versions of the plan and stored in the project’s document repository.

D-06.1.02 Technical

Architecture Document

1. A collaborative workshop is held with TEA technical stakeholders and the vendor's technical team to discuss and finalize the technical architecture of the application.

2. The workshop covers:

• Technology stack selection

(programming languages, frameworks, libraries)

• Integration points with existing TEA systems

• Platform dependencies (e.g., operating systems, cloud providers)

• Scalability and performance considerations

3. The workshop concludes with an agreement on the technical architecture that aligns with TEA's existing infrastructure, budget, and timeline constraints.

4. A comprehensive document outlining the finalized technical architecture is produced, including:

• Technology stack description and rationale

• System architecture diagrams

• Integration points and data flows

• Scalability and performance considerations

• Security architecture and controls

5. The vendor will conduct a feasibility and risk assessment based on the approved integration plan and technical architecture.

6. The assessment identifies potential challenges, risks, and mitigation strategies.

7. The assessment is presented to TEA for review and approval.

8. Technical architecture documented, reviewed, and formally approved.

9. Feedback is collected and incorporated into the final versions of the document and stored in the

D-06.1.03 Application

Coding Standards Document

1. Comprehensive Documentation: A detailed document outlining the coding standards used for each relevant technology (.NET, Java, SQL) is provided.

2. Coverage: Coding standards cover the following aspects comprehensively:

• Naming Conventions: Consistent and meaningful naming conventions for variables, functions, classes, and other identifiers.

• Indentation and Formatting:

Guidelines for code indentation, spacing, and formatting to enhance readability.

• Comments: Clear expectations for code comments, including their purpose (explaining why, not just what), usage instructions, and parameter descriptions.

• Error Handling: Best practices for handling exceptions, errors, and logging, including error code definitions and logging levels.

• Security: Guidelines for secure coding practices, such as input validation, sanitization, and protection against common vulnerabilities (e.g., SQL injection, cross-site scripting).

• Performance: Recommendations for optimizing code performance, including efficient algorithms, data structures, and memory management.

3. Accessibility Compliance: The chosen coding standards, especially for public-facing web applications, adhere to the WCAG, ensuring compliance with accessibility requirements.

4. Stakeholder Approval: TEA technology stakeholders review and approve the application coding standards, ensuring alignment with accessibility requirements, best practices, and any TEA-specific guidelines

5. Collaborative Format: The Application Coding Standards document is created in a collaborative format (e.g., shared document, wiki) accessible to both the vendor and the TEA Technical Team Lead.

6. Version Control: The document is version-controlled (e.g., using Git) and maintained throughout the project, with a clear history of changes and updates.

7. Formal Review: The TEA Technical Team Lead conducts a formal review of the coding standards before development begins.

8. Approval Sign-off: Written approval is provided by the TEA Technical Team Lead, indicating that the coding standards meet TEA's expectations for code quality, maintainability, and accessibility.

9. The vendor will address any feedback or questions raised by the TEA Technical Team Lead during the review period, revising the document as needed.

10. Upon completion of the review and any necessary revisions, the TEA Technical Team Lead will provide written approval to confirm acceptance of the final Application Coding Standards document.

11. Coding standards approved prior to commencement of development.

12. Coding commences in strict adherence to the finalized coding standards

D-06.1.04 Source Code Management & Build Process Plan

1. SCM System and Configuration:

Details the source code management (SCM) system (Bitbucket) and its configuration.

2. Repository Structure: Clearly defines repository structure, including branching strategies (e.g., Bitbucket) and naming conventions.

3. Access Controls: Outlines access controls and permissions for different user roles (e.g., developers, testers, administrators), ensuring appropriate security and segregation of duties.

4. Backup and Recovery: Documents procedures for regular backups of the code repository and outlines steps for recovering from data loss or corruption.

5. Versioning: Specifies how code versions will be tracked and managed (e.g., semantic versioning) to ensure traceability and facilitate rollbacks if needed.

6. Build Steps: Outlines the steps involved in building the application from source code, including:

7. Dependency management (e.g., package managers like npm, Maven) and strategies for handling dependency vulnerabilities.

• Compilation and linking processes, including compiler options and optimization techniques.

• Testing procedures (unit tests, integration tests, and any other relevant types) and test coverage thresholds.

• Artifact generation (e.g., executable files, deployment packages) and artifact repository details.

8. Build Environments: Specifies the build environment and tools required (e.g., build servers, continuous integration tools), including their versions and configurations.

9. Build Instructions: Provides clear, step-by-step instructions for developers to execute the build process locally and in automated environments (e.g., CI/CD pipelines).

10. Code Reviews: Defines the code review process, including roles and responsibilities, review criteria, cadence of code walkthroughs, and approval workflows.

11. Security: Addresses security considerations in both source code management (e.g., access controls, repository security) and the build process (e.g., vulnerability scanning, secure build environments).

12. Scalability: Considers how the build process can scale to accommodate larger codebases and development teams in the future.

13. Documentation Generation: Specifies how project documentation (e.g., API documentation, technical specifications) will be generated and maintained alongside the source code.

14. The Source Code Management & Build Process Plan is created as a shared document accessible to both the vendor and the TEA IT DevOps team.

15. The document is version-controlled and maintained throughout the project, reflecting any changes or updates to the SCM or build process.

16. The TEA IT DevOps team reviews and approves the plan before development begins.

17. Approval signifies that the plan aligns with TEA's development standards, infrastructure, and deployment practices

18. The vendor will address any feedback or questions raised by the TEA IT DevOps team during the review period.

19. The plan is updated as needed to reflect agreed-upon changes.

20. Upon completion of the review and any necessary revisions, the TEA IT DevOps team will provide written approval to confirm acceptance.

21. SCM and build process approved and implemented in TEA environments.

22. The finalized plan is implemented, and the source code repository and build process are established according to the plan.

D-06.1.05 Access Standards & Privilege Documentation

1. The documentation clearly defines all user roles within the application and their associated access levels and privileges.

2. Roles are aligned with TEA's organizational structure and security policies.

3. Privileges are granular, specifying what actions each role can perform within the application (e.g., view, edit, create, delete).

4. Special consideration is given to sensitive data or functionalities, ensuring appropriate access restrictions are in place.

5. If applicable, the documentation details the integration of the application with TEA's Active Directory (AD) or Identity Management (ID) systems.

6. Integration ensures seamless user authentication and authorization based on existing user accounts and roles within TEA's systems.

7. Documentation covers the technical implementation details of the integration, including data synchronization, authentication protocols, and error handling.

8. The documentation is created in a collaborative format (e.g., shared document, wiki) accessible to both the vendor and the TEA Technical Team.

9. The documentation is maintained throughout the project, reflecting any changes or updates to access requirements.

10. The documentation is reviewed and approved by the TEA Technical Team before application access is granted to any users.

11. Approval signifies that the access standards and privilege requirements align with TEA's security policies and operational needs.

12. The vendor will address any feedback or questions raised by the TEA

Technical Team during the review period.

13. The documentation is updated as needed to reflect agreed-upon changes.

14. Upon completion of the review and any necessary revisions, the TEA Technical Team will provide written approval to confirm acceptance.

15. Access standards approved; roles, permissions, and identity integration confirmed.

16. Following documentation approval, user accounts and access privileges will be provisioned within the application according to the defined standards.

D-07.1.01 OneApp – Grant Management Modules

1. Core grant lifecycle functionality is implemented and operational:

2. Grant setup, application intake, review, scoring, award, amendments, and close-out

3. Role-based access enforced for LEA, ESC, and TEA users

4. All functions execute successfully without Highest or High defects

5. Data validations prevent incomplete or non-compliant submissions

6. Demonstrated with real or representative data

7. Demonstrated in testing environment with end-to-end scenarios

8. Grant management modules delivered, demonstrated, piloted, and user accepted in the testing environment

9. TEA Product Owner provides written acceptance

D-07.1.02 OnePlan – Planning Modules

1. Planning workflows (district/campus plans) are fully functional

2. Plans can be created, edited, versioned, and submitted

3. Integration points with grant modules are operational where applicable

4. Data persistence and retrieval validated

5. Demonstrated with real or representative data

6. Demonstrated in test environment with sample plans

7. All functions execute successfully without Highest or High defects

8. Planning modules delivered, demonstrated, piloted, and user accepted in testing environment

9. TEA Product Owner approval provided

D-07.1.03 Performance Management Module

1. Performance indicators, targets, and progress tracking are functional

2. Metrics align with defined business requirements

3. Reporting outputs are accurate and reproducible

4. Demonstrated with real or representative data

5. All functions execute successfully without Highest or High defects

6. Performance management module delivered, piloted, and user accepted in the testing environment

7. TEA Product Owner approval provided

D-07.1.04 OneApp, OnePlan, and Performance Management Integration

1. Data flows correctly between OneApp and OnePlan

2. Referential integrity maintained across systems

3. Integration failures are logged and recoverable

4. End-to-end integration scenarios demonstrated in the test environment

5. Demonstrated with real or representative data

6. All functions execute successfully without Highest or High defects

7. End-to-end integration validated, piloted, and user accepted across grants and planning in the testing environment

8. TEA technical approval provided

D-07.1.05 In-App

Communication Module

1. In-app notifications, messages, and alerts function as required

2. Messages are role-aware and context-specific

3. Delivery success and failures are logged

4. Demonstrated with real or representative data Demonstrated in testing environment

5. In-app communication features delivered, tested, piloted, and user accepted in the testing environment

6. All functions execute successfully without Highest or High defects

D-07.1.06 Dashboards and Reports

1. Dashboards display accurate, real-time or near-real-time data

2. Reports align with defined KPIs and business requirements

3. Demonstrated with real or representative data

4. Filters, exports, and role-based visibility function per documented requirements

5. Demonstrated with representative datasets

6. Dashboards and reports delivered, validated, piloted, and user accepted in the testing environment.

7. TEA Product Owner approval required D-07.1.07 Immutable Audit

Logs

1. All critical actions are captured in immutable audit logs

2. Logs cannot be altered or deleted by end users or admins

3. Audit data is searchable and exportable for compliance

4. Demonstrated audit scenarios provided in the test environment for all action types

5. Demonstrated with real or representative data

6. TEA security and compliance approval received

7. All functions execute successfully without Highest or High defects

8. Immutable audit logging implemented and compliance verified by users in the testing environment

D-07.1.08 Data Retention and Archiving

1. Data retention rules implemented per TEA policy

2. Archiving processes execute successfully and within a reasonable timeframe

3. Demonstrated with real or representative data

4. Archived data remains retrievable and auditable

5. Retention schedules documented

6. Retention and archiving rules implemented and user accepted in the test environment

D-08.1.01 Front-End Code 1. Front-end code (HTML, CSS, JavaScript) adheres to established coding standards and best practices, promoting readability, maintainability, and consistency.

2. Code is properly styled and formatted using a consistent style guide (e.g., Prettier, ESLint) for visual clarity and ease of understanding.

3. Front-end code meets the latest Web Content Accessibility Guidelines success criteria.

4. An accessibility audit report is provided, confirming compliance, and addressing any identified issues.

5. Code incorporates semantic HTML, ARIA attributes, and other accessibility best practices to ensure usability for users with disabilities.

6. All core application sections (as outlined in the project scope) are fully developed and functional.

7. Navigation between sections is intuitive, seamless, and accessible.

8. Interactive elements (buttons, forms, etc.) are user-friendly and function as expected.

9. Front-end code seamlessly integrates with back-end systems (e.g., APIs) to fetch and display data accurately.

10. Data is displayed in the user interface in a clear, organized, and accessible manner.

11. User input is validated on the front-end to ensure data integrity and security.

12. Meet TEA’s IT Style Guide requirements

13. Comprehensive knowledge transfer sessions are conducted with the TEA's internal or designated development team.

14. Session’s cover:

15. Coding best practices and conventions used in the project

• Technical decisions made during development, along with their rationale

• Troubleshooting tips and common issues

• Maintenance and update procedures for the front-end codebase

16. Detailed technical documentation is provided, including:

17. Code structure and organization

• Component descriptions and usage instructions

• Data flow diagrams

• Decision logs detailing technical choices and alternatives considered

• Unit tests are developed for each user story to validate the functionality described in the story.

18. Unit tests are executed as part of the development process and pass successfully, demonstrating that the code implementation meets the requirements of the user story.

19. All user stories assigned to a sprint are completed and meet their acceptance criteria within the committed timeframe.

20. Completed user stories are demonstrated to TEA stakeholders for review and approval.

21. The completed front-end code is integrated into the TEA's version-controlled source code repository (e.g., Git).

22. The codebase is well-organized with clear commit messages and a meaningful branching strategy.

23. The repository is accessible to designated TEA personnel.

24. The vendor will address any feedback or issues raised during the review period, ensuring that the code meets TEA's standards and expectations.

25. Front-end development completed within the committed sprint and resides within TEA source control

26. Upon successful completion of the review and any necessary refinements, TEA will provide written approval to confirm acceptance.

D-08.1.02 Back-End Code 1. All core functionalities (as outlined in the project scope) are fully implemented and functional.

2. Business logic is correctly implemented and meets the specified requirements.

3. Custom code is well-structured, maintainable, and adheres to coding standards.

4. Data validation and sanitization are implemented to prevent security vulnerabilities.

5. Back-end systems meet agreed-upon performance benchmarks (e.g., response times, throughput).

6. Systems are designed for scalability to handle future increases in load and data volume.

7. Systems are highly reliable with minimal downtime.

8. Error handling and logging mechanisms are in place to facilitate issue identification and resolution.

9. Comprehensive documentation is provided for the following:

10. Security and integration plan documented

11. Deployment and maintenance procedures

12. Hands-on training workshops are conducted for TEA technical leads, covering core features, application management, troubleshooting, and best practices.

13. Unit tests are developed for each user story to validate the functionality described in the story.

14. Unit tests are executed as part of the development process and pass successfully, demonstrating that the code implementation meets the requirements of the user story.

15. All user stories assigned to a sprint are completed and meet their acceptance criteria within the committed timeframe.

16. Completed user stories are demonstrated to TEA stakeholders for review and approval.

17. The vendor will address any defects or issues identified during the review period.

18. Back-end code completed, tested, and accepted

19. Upon successful completion of defect remediation, verification, and vendor-led training workshops, TEA will provide written approval to confirm acceptance.

D-08.1.03 APIs and Data Integration

1. Comprehensive documentation is provided for the API specifications and usage

2. RESTful APIs are implemented according to the agreed-upon specifications (e.g., OpenAPI/Swagger documentation).

3. APIs handle requests and responses correctly, including proper error handling and status codes.

4. API endpoints are secured using appropriate authentication and authorization mechanisms.

5. APIs perform efficiently under expected load and usage scenarios.

6. Back-end components are seamlessly integrated with front-end components and any third-party systems (if applicable).

7. Data flows correctly between different components and systems without errors.

8. Back-end code meets all security standards as outlined in the project's security requirements and aligns with the approved integration plan.

9. APIs implemented, secured, tested, and accepted

10. Regular security audits and vulnerability assessments are conducted to ensure ongoing security compliance.

D-08.1.04 Data Models & Data Dictionaries

1. Data models accurately represent the project’s requirements and relationships between entities using industry standard third normal form (3NF), code tables, and a composite natural primary key (business key) instead of an auto-generated surrogate primary key where possible.

2. Data dictionaries comprehensively define all data elements, including data types, formats, constraints, relationships, and the exact purpose, meaning and usage of each element.

3. Data models are compatible with and can be successfully imported into Idera ER/Studio for visualization and analysis.

4. Data models and dictionaries adhere to industry best practices and TEA's data standards (if applicable).

5. Naming Conventions: Consistent and meaningful naming conventions for tables, columns, relationships, and other database objects.

6. Data Types…