Risk and Issue Log FROZEN FOR ITBM MIGRATION

Notes

Unless stated all risks and issues are owned by the Project Manager.

Guidance for RAG status assessment (as per NGMS definitions) when required

Add: category, risk owner, due/review date, in cause/effect/consequence

Issues:

• Green = Urgency and impact scored < medium
• Amber = Urgency or impact scored medium
• Red = Urgency or impact scored high

Risks:

• Green = Impact and likelihood < medium
• Amber = Impact and likelihood medium/high
• Red = Impact and likelihood >= high

Issues (risks that are presently occurring)

External software dependencies

• Impacts : Frequent breakages; stuck at old version; security
• Urgency (if issuse) : Low
• Impact : Medium
• Likelihood (if risk) : Occurring
• Mitgation + Target Score : Fab is taking a cautious approach to using external libraries; writing in Python3 will ensure good availability of dependencies when they are used. Currently technically an issue due to a problem with GCC version changing on GitHub actions. Tactical and long-term mitigations are proceeding well. Target- At plausible target
• Review date : Oct-22

Risks (but are not presently occurring)

Staff absence, loss or redirection

• Impacts : Slow down delivery
• Urgency (if issuse) : ----
• Impact : Low/Medium
• Likelihood (if risk) : Low/Medium
• Mitgation + Target Score : Contractors have settled in well and MO staff are engaging well. Target- at realistic target. Will escalate once contractors leave.
• Review date : Jul-22

Fab does not work for key customers

• Impacts : Failure of project
• Urgency (if issuse) : --
• Impact : High
• Likelihood (if risk) : Low
• Mitgation + Target Score : Pre-project work consulted extensively with customers and stakeholders; project team have good understanding of existing solutions; main customers can continue to use existing solutions; carrying out early user testing. At target.
• Review date : Oct-22

Missed requirements

• Impacts : Time or quality of products
• Urgency (if issuse) :
• Impact : Medium
• Likelihood (if risk) : Low
• Mitgation + Target Score : Pre-project work consulted widely with internal customers with good knowledge of existing and anticipated requirements of MO and collaborators' needs; collaborators are not mandated to use Fab; involvement of external parties will be phased in as project progresses. Target- at target
• Review date : Oct-22

Collaborator delivery of promised developments

• Impacts : Affect on time or quality
• Urgency (if issuse) :
• Impact : Medium
• Likelihood (if risk) : Low
• Mitgation + Target Score : Historically, collaborators have not been great at delivering promised work; mitigation is to gradually phase in collaborator involvement as the project progresses. Target- at target
• Review date : Oct-22

Ill defined requirements

• Impacts : Affect time or quality
• Urgency (if issuse) :
• Impact : Medium
• Likelihood (if risk) : Low
• Mitgation + Target Score : Requirements gathered pre-project were collected using a good selection of customers and stakeholders; keep requirements fixed during initial implementation of software to manage external influences; phased engagement with broader audience as project progresses. Target- at target
• Review date : Oct-22

Software quality

• Impacts : Reliability issued for customers
• Urgency (if issuse) :
• Impact : Low
• Likelihood (if risk) : Low
• Mitgation + Target Score : Using standard quality approaches (eg version control, documentation, testing); development during early stages limited to experienced MO developers using buddy reviewing; appropriate working practices will be formalised as project progresses to support engagement with wider developer community. Target- at target
• Review date : Oct-22

Long term sustainability

• Impacts : Higher ongoing maintenance costs
• Urgency (if issuse) :
• Impact : Medium
• Likelihood (if risk) : Low
• Mitgation + Target Score : Choice of python3 (as opposed to python2); python skills are widely available; design principles try to minimise decisions that introduce future limitations. Target- at target
• Review date : Oct-22

Item template (ignore)

Item template

• Impacts :
• Urgency (if issuse) :
• Impact :
• Likelihood (if risk) :
• Mitgation + Target Score :
• Review date :

Known Technical/Workaround Debts

Usage of shared structures in the queue (rather than the database)

Incurred during Phase 3 whilst reworking the core part of the application. Now that the queue works off of Artifacts rather than Tasks the job of understanding relationships and ordering of execution is slightly more difficult to track. The solution currently implemented is to use a type of shared array/dictionary which is available to all worker processes. However these aren't particularly clean from a code point of view and may not be performant when we start scaling to bigger projects. It seems to make sense that the correct thing to do will be to treat the state database as our persistent memory instead, but given the scale and lateness of the task in Phase 3 there wasn't time to implement this.

Logging

To follow