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 8 Next »

📋 Background

The software tool being developed is intended to assist BC government employees, particularly TEAMS coordinators, in finding and deploying TEAMS members' talent during emergencies and disasters. The app has a 6-week deadline for the MVP delivery. The key features of the MVP phase include a login portal, dashboard screen with sort/filter functionality, and view/edit functionality of the user profile. The development team faces various challenges and uncertainties that could impact the successful and timely delivery of the application.

🤹‍♂️ Risks management

Risk management is a systematic process of identifying, assessing, prioritizing, and mitigating risks/uncertainties that may impact the achievement of objectives or the success of a project, organization, or initiative.

Risk rating

LOW

MEDIUM

HIGH

EXTREME

  • Acceptable

  • Ok to proceed

  • As low as reasonably practicable

  • Take mitigation efforts

  • Generally unacceptable

  • Seek support

  • Intolerable

  • Place event on hold

Likelihood

Improbable

Possible

Probable

  • Risk is unlikely to occur

  • Risk will likely occur

  • Risk will occur

Severity

Acceptable

Tolerable

Undesirable

Intolerable

  • Little to no effect on event

  • Effects are felt, but not critical to outcome

  • Serious impact to the course of action and outcome

  • Could result in disaster

Risk Description

Ratings

Likelihood

Severity

Risk Rating

Issues supporting IDIR Logins

Need to be in touch with external team to ensure client setup

Possible

Tolerable

Medium

We don’t know which realm this application will sit in for all roles

Possible

Tolerable

Medium

Roadblocks working with Postgres + CrunchyDB

Less familiarity with setup process of Patroni/ CrunchyDB

Possible

Tolerable

Medium

Need time to ensure proper backup and restore setup

Possible

Tolerable

Medium

Stack Choice: OpenShift is less familiar with the devs

Less familiarity with setup process

Possible

Tolerable

Medium

Can we tap into pros at EY if we run into roadblocks?

Possible

Tolerable

Medium

If we need storage or email options, external service needed

Possible

Tolerable

Medium

Illnesses + time-off will affect progress & momentum

Team away on break during Christmas week

Probable

Undesirable

High

Issues setting up Vanity URL

Vanity URL marked as "yes" by Dea / Keyvan

Possible

Undesirable

High

Approval process and possible complications

Possible

Tolerable

Medium

Unknown Future State / Features of application

Documentation for future development time

Possible

Undesirable

High

Need to cover for Dea’s 2 Weeks Vacation

Impact on momentum and stakeholder involvement

Possible

Undesirable

High

Time for UI/UX design starts as development begins

Design back-and-forth might cause delays

Possible

Tolerable

Medium

Lack of Feedback time before Freshet

System use during Freshet is desired but uncertain timeline

Possible

Tolerable

Medium

Unknown magnitude of tasks – how much will they ease the process?

Limited user interviews and research time

Possible

Tolerable

Medium

What do we need in terms of PIA, STRA, and other governance bits?

Assigning someone for forms/processes

Possible

Undesirable

High

Little time between ticket refinement and implementation

Constant refinement/planning/implementation

Possible

Undesirable

High

Onboarding Users to KeyCloak

Onboarding users to KeyCloak

Possible

Tolerable

Medium

App Availability in Emergency Situations

Is it necessary for the app to stay operational during emergencies? Yes

Possible

Intolerable

Intolerable

✅ Action items

  •  
  • No labels