Skip to end of banner
Go to start of banner

UTAH Application launch and migration - Retrospective

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

\uD83D\uDCCB Overview

Reflect on past work and identify opportunities for improvement by following the instructions for the Retrospective Play.

Date

Participants

\uD83D\uDCAD Retrospective

What went well

What did not go well

What can IT do to support a smoother implementation/deployment?

There was no update on the applications that had been migrated over. We had no idea which ones had already been migrated over.

The documents in the applications were migrated over and placed under qualifying question documents.

MASS applicants were re-directed to apply for UT, CO and Texas. This is still an ongoing issue.

Issue with system emails to the applicants stating “none selected” instead of DORA.

The system was giving 5 year approvals for applicants, instead of the 1 year approval they should have received.

Errors in Central were being received when processing approvals.

Errors received in Central when trying to send problem emails.

The applicant’s DL number was not a required field in the application.

SSN issues.

The School Codes were not saving in the applications.

Applicants could not submit their application because the system stated that they already had a login. However, when they ask the system to re-set their password and enter the login, the system did not recognize that login information - LMR-7146.

There is a long lag time between when someone creates their login and they are able to use it.

More thorough testing needed by MSERV staff prior to deployment.

MSERV staff working changing items in old program during the migration.

Changes/issues reported by different staff using multiple methods.

MSERV staff not aware of items fixed/completed during migration.

Staff not using old program when data had already been migrated.

During migration an unrelated issue started with ASWBCentral performance.

Updates were posted on Central site, but updates to site not regularly relayed

IT should have had a Migration Plan that stated what applications were being to be migrated over each day.

Migrations should be completed in phases, not all at once to minimize the impact to customers.

There should be daily updates provided by IT as to where we are in the migration plan.

The issues experienced after the migration did not happen when we were testing Utah. We need to know why the problems were experienced during the migration.

Our group should not be troubleshooting system issues with the applicants as we are not IT and do not have the knowledge base that IT would have on systems.

There should be no impact to applicants for other states (CO, TX, MA).

Issues/changes/new requirements brought up during the deployment that were either not tested or noted as not needed for deployment.

Have a blackout period in place during deployment until the go ahead is given by IT to work in the system. Have one staff at a time work in production to identify any initial issues.

Identify single point of contact for department who reports issues/changes.

Single source page was created to help with the problem above of varied reports and methods, but staff was not checking the page for updates. Follow up with single point of contact to make sure all issues being addressed.

Schedule pre-deployment meeting to share information/guidelines for deployment.

Prior to new deployments IT to ensure all maintenance tasks on ASWBCentral are completed.

Have post-deployment meeting day of or day after deployment.

✅ Action items

  • No labels