A0007_RFP Attachment 4 - Sample Task 1 Existing Product Development.docx

RFP 2031JW25R00003 Attachment 4 Appian Platform and Product Support ITS SPS Sample Task 1: Existing Product Operations and Maintenance Transition and Support

1.0 BACKGROUND

In support of this mission the Office of the Comptroller of the Currency (OCC), Information and Technology Services Division (ITS) seeks to ensure a robust, secure, and seamless operational environment for the Appian Platform which remains paramount to the delivery of critical business processes and services.

2.0 PURPOSE

The purpose of this Task Order is devoted to comprehensively addressing the needs and challenges pertaining to Appian System Administration Transition and Support. Emphasizing various facets, such as software development, configuration management, technology refresh and architecture support, patch and upgrades, system maintenance, help desk support, application monitoring, product recovery, and capacity management, a multi-faceted approach is integral. This task order describes the work and approximate amount of time resources needed to spend on these activities.

3.0 SCOPE AND DESCRIPTION OF TASKS

The scope of work includes support for the following existing products:

· Assignment Management System (AMS)

· Central Application Tracking System (CATS)

· Community Reinvestment Act–Qualifying Activities (CRA)

· Common Case Management (CCM)

· Cybersecurity Supervision System (CSS)

· Examiner Portal (ExPo)

· Ethics Management System (EMS)

· Invitational Travel Reimbursements (ITR)

· National Risk Issue System (NRISK)

· Personnel Administration and Security (PASS)

· Product Search Portal (PSP)

· Quick Wins

· Security Assessment and Accountability System (SAAS)

· Strategy Tracker (Tracker)

· Supervisory Product Review Tool (SPRT)

· Web Tracking and Tracking Application (WTTA)

Tasks and Deliverables This section defines the type of tasks that may be performed and the work products and deliverables that may be created/maintained by the Contractor. Given the agile development approach described later in this document, the specific tasks and deliverables are defined in this task order and elaborated on at the start of each sprint or release. The ‘Estimated Hours & Work Allocation’ table later in this document provides an estimated percentage of time expected to be allocated to the tasks identified in this section. All deliverables are due to the COR unless explicitly stated otherwise.

3.1 Project Management Tasks

3.1.1 Project and Contract Management

The Contractor must perform all of the types of work described in Table , as necessary.

Table 3–1 Project and Contract Management Tasks

· Activities by technical/functional area

· Updates to the Integrated Master Schedule (IMS)

· Status of deliverables (submitted, late, or planned)

· Key risks and mitigation plans

· Key issues and action items

· Staff changes

· Performance metrics.

The Contractor must:

· Deliver a weekly status report, in a format agreed upon by the COR and Contractor, by the end of the first business day following the week for which status is being reported;

· Work with the OCC’s project managers and assist with inputting data into the status report or systems used to collect status report data; and

· Confirm with the COR prior to dissemination of the first report, the recipients of the weekly status (any additions to or deletions from the recipient list must be approved by the COR).

After award, the COR will provide the Contractor the mandated template for producing this report. The COR may change this template with reasonable notice given to the Contractor.

· Reiterate and confirm by providing a narrative demonstrating understanding of the project goals, needs, and objectives;

· Propose high-level technical approaches and alternatives for currently undefined, labor-hours tasks;

· Propose high-level milestones for currently undefined tasks whose level of effort is not reflected in the project schedule;

· Coordinate and collaborate with other contractors and OCC staff on planning activities; and

· Conduct project management activities across all projects included in the PWS (e.g., resource planning/constraints and coordinating, training compliance, onboarding/offboarding including timeframes, space planning support, long term integrated planning, communications channels, office location).

Quarterly

· Maintain release plans within the OCC-approved application lifecycle management (ALM) software (currently Jazz, but referred to as ALM through the remainder of this document)

· Determine release plans in quarterly meetings with the OCC ITS project team and the relevant OCC business unit stakeholders

· Schedule quarter release planning meetings, no less than three weeks prior to the planned release date.

· Calculate the estimated cost of the release, iteration, and sprint using the initial release budget, release backlog, estimated velocity. Continuously review actual release/sprint cost against the estimates and adjust future cost predictions.

The planning meeting will include activities such as backlog grooming, allocating/reallocating items to a release/sprint, discussion of story points, velocity, and resource capacity. Attendance at release/sprint planning meetings by the development team members should be included in the development tasks for each system in scope.

Implementation Plan that consists of the final implementation readiness checklist and detailed deployment checklist

These updates must include percentage of total work completed, actual effort expended on an activity in labor hours, dependency changes, resource changes, milestone changes, etc. Detailed tasks will be stored in ALM, so the project schedules will contain activities not in the ALM (e.g., document updates & reviews) and sprint/release timelines.

The Contractor is required to submit a COR Review Package by noon on the third Wednesday of each month. The version submitted by this time must be signed by the Contractor’s program manager. The COR will complete the review within a reasonable amount of time to complete their review and acceptance of the COR Review Package..

The contractor must do the following:

· Configure and update ALM dashboards as software development is performed.

· Present these required reports in monthly KPI meetings that occur on the third Wednesday of every month. If the Contractor demonstrates full adoption of SPS’s Agile methodology as reflected on the SPS Agile Heat Map, for a specific product, then it will have the opportunity to reduce the frequency of presentations to a quarterly basis for that product. The Contractor must request approval of the change of frequency to quarterly from the COR.

For Appian products with active development work, monthly ALM Reports for the KPIs (see Appendix D) must be configured no later than the third Wednesday of every month. This applies to all product development teams, regardless of the frequency of presentation meetings. For product development teams authorized to present quarterly, during the months they are not presenting, they are required to send a deliverable completion email no later than the third Wednesday of every month. The purpose of this email is to provide notification to the ITS PM, Call COR, Program COR, and the Agile SLPM Group that the team has completed its monthly report configuration updates for all development projects it supports. This email should include a link to the team’s completed ALM dashboard.

Monthly Contractor Invoice (By CLIN and product-level OCC IT project codes)

3.1.2 Quality Control (QC) Management

The Contractor must participate in ITS-sponsored quality performance improvement initiatives related to software development activities. These initiatives may include, but are not limited to, collaborative activities designed to develop software standards and conventions, protocols for naming software objects and classes, specific design approaches for error handling and system interfaces, and integration with third-party tools for automated testing as a part of continuous development and deployment (e.g., piloting of tools like Jenkins, Jira, Git). Support for OCC quality initiatives may also include the implementation of structured code reviews. The Contractor must perform some or all the types of work, as necessary, described in Table 3–2.

Table 3–2 Quality Control Tasks

3.2 Software Development Tasks

The Contractor must provide support for operations, compliance debt, technical debt, and new enhancements for the products and platforms covered by this PWS. See section 4.0 for scope of work planned for maintenance of existing products and new development work.

3.2.1 Operations, Compliance, and Business Investment

Unless explicitly excluded, the Contractor is responsible for all aspects of operations, compliance debt, technical debt, and new enhancements activities. These activities include the following:

· creating and maintaining platform and product architectural roadmap

· monitoring and documenting product tool version levels

· creating and maintaining SDLC documentation for OCC products

· analyzing and resolving software defects reported

· modifying existing software to resolve reported system problems

· managing the configuration of new and modified system software

· designing, testing, and deploying new system software (including inbound and outbound interfaces)

· repairing and recovering data for OCC systems

· managing OCC data in transit until it is received by its destination system

· implementing process improvements associated with specific maintenance activities.

The Contractor must ensure that maintenance system changes continue to meet the OCC’s functional requirements, are interoperable with other enterprise products, are consistent with the approved enterprise architecture, and meet operational expectations for system monitoring and disaster recovery. The Contractor must also proactively identify opportunities, within specific software releases or sprints, for combining software enhancements and/or code fixes in a manner that increases efficiency and/or reduces costs.

The Contractor is responsible for ensuring the acceptability of the software and associated documentation quality that it delivers, as defined in the Quality Control Plan. Sufficient unit and system testing of new and modified software, changes to configuration settings, and changes to database schemas is required to ensure the successful operation of OCC systems prior to User Acceptance Testing (UAT) or deployment into production (for changes not subjected to UAT). In the performance of its software maintenance activities, the Contractor’s team must adhere to the OCC’s processes for event, incident, problem, and change management, as well as to the OCC’s processes, policies, and procedures for security management (including the Security Assessment & Accreditation [SA&A]). The Contractor must perform some or all the types of work, as necessary, described in Table .

Table 3‑3 Operations, Compliance, and Business Investment Tasks

The Contractor must:

· Follow Agile practices. The Contractor’s Appian development staff must perform the full range of software development activities (e.g., requirements, design, development, testing, QA, and documentation tasks).

· Perform release planning for each quarterly and monthly release, based on customer assigned priority. The Contractor must manage all product-specific change requests and defect fixes within the OCC's enterprise configuration management tool. There is a maximum of five (5) defects and a minimum of two (2) changes requests in each quarterly release for each product. There is a maximum of one (1) defect in a monthly release for each product.

· Use agile development principals to manage product-specific work items, including relative estimation (story points) for unapproved change request.

· Convene a biweekly sprint planning meeting to obtain:

1. clarification on outstanding requirements

2. signoff on acceptance criteria from the Business Unit on all defect fixes and change requests included in the sprint. Development on said defect fixes and change requests may not begin until BU approval is obtained on the acceptance criteria.

· Deliver a sprint planning slide deck. The slide deck should cover the following information (at a minimum) for each item being presented:

-ID

-Description/Summary -Acceptance Criteria -High-Level Design Plan -Found By -Priority

· All functional requirements are met

· All audit requirements are met

· Designs meet the OCC’s disaster-recovery standards

· Designs minimize data loss and downtime

· Designs are sufficiently documented and traceable to one or more requirements

· Designs are testable

· Designs are flexible and extendable for future needs

· Designs are flexible and extendable to support data migration from legacy systems The Contractor must do the following:

· Design Product specific changes requests and defect fixes according to OCC defined best practices and standards

· Design specifications meet the acceptance criteria agreed upon with the Business Unit

· Coordinate significant change requests/integrations with the Appian Platform and Enterprise Architecture teams (e.g., integration with a new system inside or outside of the OCC)

· Document the design and implementation of any new functionality which takes more than 40 hours to implement, in a requirements/design document. Examples of new functionality may include implementing a new component or workflow, design a new integration (e.g., OCR, Interface with GetITHelp)

· Apply Appian and OCC UI/UX customer/user centered design concepts and best practices for Appian development

· Evaluate the overall digital experience of Appian products (new and existing) across desktop and other relevant screen sizes

· Gather qualitative data to build an understanding of user needs through user interviews or contextual observation

· Identify trends and patterns across the information collected during UI/UX research.

· Identify areas of UX improvement and provide recommendations for a path forward

· Develop and maintain UX & UI recommendations and best practices to improve the user experience across the Appian platform

· Design detailed mockups and designs that can be used directly by developers to build custom software or interfaces

· Deliver User Experience (UX) flows, wireframes, high fidelity mockups, interactive prototypes, design specifications, and final components

· Translate user needs and requirements into elegant solutions, concepts and interaction models that scale and fit within larger established systems and patterns

· Develop personas and use cases

· Configure/build development, prototyping, and test environments to support the development and testing of modified or new software

· Coordinate with the Infrastructure and Operations (I&O) team to implement required technology environment changes

· Develop software to support the implementation of new or revised system requirements

· Develop software/programs/scripts to support data migration from legacy systems

· Configure COTS software to support the implementation of new or revised system requirements

· Design, create, and/or maintain (if already existing) the product architecture

· Design, create, and/or maintain (if already existing) the product business databases

· Identify any necessary database changes to be conveyed to the Database Administrator for implementation

· Coordinate the scheduling of database maintenance with the database-administration team

· Leverage the OCC’s existing development tools and recommend new third-party tools to improve developer productivity, code stability, and code reusability.

The Contractor must do the following:

· Develop Product specific change requests and defects using OCC defined best practices for Appian development.

· Perform technical code reviews on all work items developed as part of a quarterly or monthly release. The code reviews must be performed by a technical lead, who is familiar with the OCC defined best practices for Appian development and has an Appian Lead Developer Certification.

· Design and develop all Product specific change requests and defect fixes using Appian out of the box configurations and code as much as possible.

· Demonstrate release-worthy functionality for each sprint within a quarterly release.

· Create and maintain product-specific test plans, test scripts and test cases that utilize the appropriate SDLC document templates.

· Create and maintain requirements traceability matrices (RTMs).

· Utilizing OCC approved automated test and performance test tools, create, and maintain automated test scripts that can be reliably executed in a repeatable fashion.

· Conduct regression, functional, integration, and system testing in a dedicated test environment that is isolated from Production.

· Conduct installation testing in a dedicated staging environment that is isolated from Production.

· Create and maintain product-specific test results that utilize the appropriate SDLC document templates. These test results should represent the output of executing the test cases identified in the relevant test plan.

· Perform security testing of new, modified, and reconfigured software

· Create and maintain simulation data for development, testing, and training purposes. To the extent possible, these data sets should be created and maintained so that they can be re-used for testing across multiple products. This task will include the following:

· Work with business-unit and IT stakeholders to identify confidential data that requires protection

· Create and maintain a process for creating simulated data, including a process for redaction

· In situations where simulated data cannot be used for testing, secure the testing data to ensure that no Personally Identifiable Information (PII) is compromised during testing.

· Adapt the testing instance of a product, where necessary, to protect PII during testing

· Consult with the appropriate DBA team to implement database-level protection strategies

· Conduct weekly tests of the products to ensure that the implementation of Microsoft security patches has not negatively impacted the products

· Create and maintain disaster recovery test plans and conduct annual disaster recovery tests.

The Contractor must do the following:

· Write test scripts using approved OCC Enterprise tools for automated (e.g., Selenium) and manual testing (e.g., Rational Functional Tester) for all defect fixes and change requests.

· Use the OCC's approved enterprise performance testing tool (currently Rational Performance Tester) to perform performance testing for a Product release on an as-needed basis.

· Support OCC Security team on performing continuous security testing on any of the Products on the Appian Platform and related components (e.g., IIS web server, JBoss application server, SQL relational database)

· Support User Acceptance Testing for each major release for each Product.

· Use OCC's approved accessibility technology tool to perform 508 testing for each major release for each Product.

· Perform integration testing for all major and minor releases for each Product. This effort is estimated to take a minimum of 40 hours per month.

Test Plans, Test Scripts, and Test Cases (Create and/or update scripts for product. The method of delivery is to place in the OCC’s ALM.)

Variable

Electronic Deliverable

As part of product monthly or quarterly releases, as needed

Requirements Traceability Matrices (RTMs) (Create and/or update scripts for product)

Variable

Sprint Test Results stored in ALM

The Contractor must do the following:

· Generate release notes using the acceptance criteria defined in the OCC's enterprise configuration management tool for each major and minor release for each product. The release notes must be created at a minimum of 5 days before the release deployment.

· Maintain the user guides and any other communication/training material for each product.

The Contractor must do the following:

· Present changes to the design of the system at both the Enterprise Review Group (ERG) and Enterprise Change Control Board (CCB) as part of the release management process to ensure that other OCC applications are not impacted by the upcoming system release

· Perform integration, regression, and end-to-end testing for all major releases of a product on the platform. The testing must include validation of product-specific interfaces (e.g., EIR, AEM, BankNet)

The Contractor must do the following:

· Submit requests for all developer and testers for the install of OCC Enterprise Configuration Management tools (currently Rational tools) immediately after adding the resource to the project team

· Submit requests for access to the appropriate ALM project area(s) immediately after adding the resource to the project team

· Ensure its employees are fully trained in the use of the ALM application prior to being added to the project team

The Contractor must do the following:

· Review and maintain the Appian Platform and product-specific best practices, procedures, and tips & tricks in the OCC's Center of Excellence application.

· Convene a biweekly best practice meeting to discuss new best practices/standards as well as updates to existing best practices/standards.

Development Standards

(Update the OCC’s Center of Excellence application. Subject to approval by the OCC’s Appian Architect.

Variable

Electronic Deliverable

Biweekly, as needed

The Contractor must review and maintain the Appian Platform and product-specific best practices, procedures, and tips & tricks in the OCC's Center of Excellence application.

Maintenance Standards and Checklists

(Update the OCC’s Center of Excellence application) Variable

Electronic Deliverable

Biweekly, as needed

Refer to assumptions identified in 3.2.1.1.

System Administrator Guide. See the embedded file for the required content, format, and organization of the guide.

Annual review and update at the beginning of the fiscal year.

Environment Diagrams for development and production environments of each Appian product. See the embedded files for the required content, format, and organization of the document.

Secure Baselines for product components, which includes the OCC Enterprise baseline with tailored settings for each Appian product and its components (e.g., Appian, IIS)

Information System Contingency Plan (ISCP) See the embedded file for the required content, format, and organization of the document.

Information System Contingency Plan (ISCP) Table-top exercise. Includes presentation, simulation, and after-action report. See the embedded files for the required content, format, and organization of the document and presentation

Lessons Learned Meeting Minutes

(Sessions will be held each month, with a duration of no more than one (1) hour per session)

Within one (1) business day after the meeting

Sprint Planning Slide Deck comprised of the defects and change requests planned for a sprint

One (1) presentation per sprint per product

A Customer Demo at each iteration review that demonstrates the release-worthy items for the sprint

One (1) demo per sprint per product

3.2.2 Configuration and Release Management

The Contractor is responsible for the configuration management (CM) of all products within its area of responsibility using OCC provided CM tools. The Contractor must implement processes and controls to ensure that software configuration management is consistent with the OCC’s standards and industry best practices. In performance of its CM duties, the Contractor must follow the ITS Release Management Plan and the ITS Enterprise Configuration Management Plan. The Contractor must execute the processes and procedures set forth in these two documents in a uniform, standardized, and auditable manner. Moreover, the Contractor must support the OCC in initiatives including automated and continuous deployments (devops) using third-party tools that integrate with and support the Appian commercial off-the-self (COTS) product. The Contractor must perform some or all the types of work described in Table .

Table 3–4 Configuration and Release Management Tasks

3.2.2.1

Release Management Process: The Contractor must install all production releases during the designated after-hours timeframe. To the extent possible, the implementation of the release should be executed without significant degradation to the product’s performance and with minimal interruption to user access.

The Contractor must install major and minor Appian platform and product releases outside of normal OCC business hours. This effort is estimated to take a minimum of 4 hours.

Monthly

Release Notes comprised of the business unit-approved acceptance criteria for each defect fix and change request in the release. See the embedded file for the required content, format, and organization of the release notes.

The Release Installation Package

One (1) package per product release

Electronic Deliverable

Delivered two (2) business days after the end of the last sprint

Delivered by the last calendar day of the release

Delivered two (2) business days after the end of the last sprint

Quarterly

Appian Health check (logs/analysis) See the embedded files for the required content, format, and organization of the document and presentation

Delivered one (1) business day after the end of the last sprint

3.2.3 Technology Refresh, Architecture Support, and Research

The Contractor must research and recommend new technologies and products that will assist the OCC in implementing a comprehensive set of tools, techniques, and methods to conduct System Engineering/Architecture activities. Success factors for research and analysis include recommendations that consider: 1) Technical Feasibility of proposed technologies (e.g. compatibility with existing systems and infrastructure), 2. Scalability and Flexibility, 3. User Experience (selection of technology that provides an intuitive UI/UX) and 4. Regulatory and Security Compliance. The Contractor must perform some or all the types of work described in Table , as necessary.

Table 3–5 Technology Refresh, Architecture Support and Research Tasks

The Contractor must do the following:

· Support the OCC PMs with planning for MS SQL database upgrades for all Appian products This effort is estimated to take a minimum of 8 hours a year.

· Support the OCC integration teams with LDAP/Active Directory upgrades that impact Appian products

· Work with the OCC’s Appian vendor and the OCC Enterprise Database Management team to create a plan for database encryption for all Appian applications using a relational database (e.g., MS SQL)

· Support .Net upgrades which impact the Corporate Application Search (CAS) application within the CATS Boundary. This effort is estimated to take a minimum of 4 hours per year.

· Update deliverables within 30 days of identification of the need for an update.

· Create an evaluation model to assess the third-party software currently utilized by ITS

· Conduct a gap analysis of the capabilities offered by the OCC’s existing third-party products within the portfolio and identify appropriate measures to remediate the gaps

· Utilizing this gap analysis, recommend new third-party software products, or upgrades to products currently utilized by the OCC, that will best address the agency’s business needs

· Identify opportunities to eliminate existing custom solutions and/or code elements within those solutions and replace them with a COTS product.

· Conduct knowledge transfer with OCC technical SMEs regarding the features of newly installed third-party software and tool upgrades.

· Proactively research, evaluate, and recommend new technologies, infrastructure modifications, industry-leading practices, and other innovations to provide the OCC a state-of-the-art IT environment

· Conduct market research for technology advancements

· Conduct evaluations of technology advancements in a research-lab environment

· Evaluate, assess, and compare different commercially available technologies using a Capability Maturity Model Integration (CMMI)-compliant Decision Analysis and Resolution (DAR) process

· Conduct trade-off analyses, identifying the advantages and deficiencies of competing technology products

· Determine if the introduction of a software upgrade into the infrastructure will impact the performance of production products.

· Participate in ITS joint engineering meetings

· Create white papers, presentations, and briefings that address architectural topics identified in the joint engineering meetings as candidates for research.

· Proactively research, evaluate, and recommend new technologies, infrastructure modifications, industry-leading practices, and other innovations to provide the OCC a state-of-the-art IT environment

· Conduct market research for technology advancements

· Conduct evaluation of technology advancements in a research-lab environment

· Evaluate, assess, and compare different commercially available technologies using a Capability Maturity Model Integration (CMMI)-compliant Decision Analysis and Resolution (DAR) process

· Conduct trade-off analyses, identifying the advantages and deficiencies of competing technology products

· Determine if the introduction of a software upgrade into the infrastructure will impact performance of production products.

3.2.4 Product Testing, Training, and Implementation

The Contractor must follow OCC direction in conducting software testing activities. The Contractor must conduct unit, integration, system, performance, and regression testing to confirm that the new, modified, and/or reconfigured code successfully addresses the requirements with the specified level of quality. The testing must be accomplished in accordance with the OCC’s ITS SDLC and IT Governance policies. The following objectives apply for testing of all products in scope:

· Each product developed, configured, and maintained must have a comprehensive test strategy and underlying test plan(s) aligned with ITS processes, standards, and procedures.

· Tests for each product release will directly address all requirements and components of the design so that the project team and stakeholders can verify and validate that the identified business need has been met.

· Product leads and project teams will implement measures that ensure all data and information related to testing is maintained throughout the life cycle of the project.

· For situations where the Enterprise Test Lab (ETL) is not available for product testing, provide a testing environment that emulates, to the extent possible, the production environment so that product testing can be performed.

· All test planning activities will be verified as complete (per Appian COE guidelines) before testing begins.

· Where possible, testing will be automated to improve efficiency and accuracy.

· All planned tests will be performed prior to system release to verify that a solution fully addresses all user requirements.

· Where possible, tests will be conducted independently by a team other than the original project team to verify and validate that the test results accurately reflect the system performance.

· Solutions for desktop release will be tested to confirm that they deploy and install properly on a standard ITS workstation. Performance testing will be conducted to verify that the solution is robust and scalable under increased load. Test results will be collected and analyzed during the test cycle to verify progress against the testing plan and to quickly find any deviations. When delays are encountered, test plans will be adjusted, if possible, to meet the original schedule without compromising the quality of the solution. Defects found during testing will be identified, categorized, and prioritized in a timely fashion to identify the code fixes that must be made before deployment, as well as the code fixes that can be deferred without compromising the quality of the solution.

The Contractor must perform all the types of work described in Table 3–6, as necessary.

Table 3–6 Product Testing Tasks

· Create and maintain UAT test plans, test scripts, test cases, and test results

· Consult with the relevant OCC stakeholders regarding acceptance criteria for the release of the code into production. Document these criteria for use during UAT.

· Coordinate and schedule UAT execution with the appropriate OCC participants

· Create and maintain release notes to communicate to UAT testers the software modifications that they will encounter during testing

· Correct defects and nonconformities identified during UAT. Deploy as many iterations of code as required to secure acceptance from the COR for the software to be released into production.

The Contractor must conduct user acceptance testing for all major release for each product.

This includes:

· creating test accounts for participants

· creating testing assignment spreadsheets

· obtaining and documenting test results

· troubleshooting testing errors

· analyzing and aggregating test results

· entering defects and change requests because of test efforts.

This effort is estimated to take a minimum of 24 hours per major release

User Acceptance Test Results comprised of the test results in ALM

The Contractor must do the following:

· Create a training plan.

· Create training materials for appropriate user groups. The user groups are internal Executives, Analysts, Legal and Supervision staff, Tier 1 Help Desk, and external Bankers, Attorneys and Consultants.

· Customize and make the training material relevant to their role and method of training.

· Create online training materials (either user guides, power point or video) to explain access, navigation, functions, and tasks of the application.

· Use the testing environment for training.

· Create and maintain simulation data for training purposes in the testing environment.

· Support webinars given by the Government to the user groups by providing demonstrations of the application during each session.

The training plan must include the following to support the use and maintenance of the specific system or application:

· Training Objectives

· Audience Analysis

· Training Content

· Training Materials

· Training Tools, Techniques and Methods

· Training Schedule

· Instructors and Facilitators

· Support and Resources

· Communications

The Contractor must do the following:

· Develop a comprehensive change management plan, outlining strategies for communication, stakeholder engagement, training, and risk mitigation, in alignment with the organization's goals and objectives.

· Assess the organization's current Agile maturity level and identify areas where Agile principles and practices can be effectively applied to support the change initiative.

· Provide Agile coaching and mentoring to business unit teams and individuals involved in the change initiative, helping them understand Agile principles, practices, and methodologies.

· Facilitate Agile training sessions and workshops for employees and stakeholders, focusing on Agile concepts, roles, ceremonies, and tools as they relate to the change.

The change management plan must include the following in alignment with Agile coaching and mentoring:

· Executive Summary

· Change Vision and Objectives

· Stakeholder Analysis

· Communication Strategy

· Leadership and Sponsorship

· Change Team and Roles

· Training and Development

· Risk Assessment and Mitigations

· Feedback Mechanisms

· Timeline and Milestones

The Contractor must do the following:

·…